RE: [RFC RESEND 2/4] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
On Thu, Aug 16, 2012 at 22:27:42, Hunter, Jon wrote:
>
> On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
> >
> >
> > On 7/14/2012 3:56 AM, Jon Hunter wrote:
> >> OMAP3 devices may or may not have security features enabled. Security
> >> enabled
> >> devices are known as high-secure (HS) and devices without security are
> >> known as
> >> general purpose (GP).
> >>
> >> For OMAP3 devices there are 12 general purpose timers available. On secure
> >> devices the 12th timer is reserved for secure usage and so cannot be used
> >> by
> >> the kernel, where as for a GP device it is available. We can detect the
> >> OMAP
> >> device type, secure or GP, at runtime via an on-chip register. Today, when
> >> not
> >> using DT, we do not register the 12th timer as a linux device if the
> >> device is
> >> secure.
> >>
> >> When using device tree, device tree is going to register all the timer
> >> devices
> >> it finds in the device tree blob. To prevent device tree from registering
> >> 12th
> >> timer on a secure OMAP3 device we can add a status property to the timer
> >> binding with the value "disabled" at boot time. Note that timer 12 on a
> >> OMAP3
> >> device has a property "ti,timer-secure" to indicate that it will not be
> >> available on a secure device and so for secure OMAP3 devices, we search for
> >> timers with this property and then disable them. Using the
> >> prom_add_property()
> >> function to dynamically add a property was a recommended approach
> >> suggested by
> >> Rob Herring [1].
> >>
> >> I have tested this on an OMAP3 GP device and faking it to pretend to be a
> >> secure device to ensure that any timers marked with "ti,timer-secure" are
> >> not
> >> registered on boot. I have also made sure that all timers are registered as
> >> expected on a GP device by default.
> >>
> >> [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
> >>
> >> Signed-off-by: Jon Hunter
> >> ---
> >> arch/arm/mach-omap2/board-generic.c |1 +
> >> arch/arm/mach-omap2/common.h|1 +
> >> arch/arm/mach-omap2/timer.c | 36
> >> +++
> >> 3 files changed, 38 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-omap2/board-generic.c
> >> b/arch/arm/mach-omap2/board-generic.c
> >> index 6f93a20..20124d7 100644
> >> --- a/arch/arm/mach-omap2/board-generic.c
> >> +++ b/arch/arm/mach-omap2/board-generic.c
> >> @@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[]
> >> __initdata = {
> >> static void __init omap_generic_init(void)
> >> {
> >>omap_sdrc_init(NULL, NULL);
> >> + omap_dmtimer_init();
> >>
> >>of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> >> }
> >> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> >> index 1f65b18..d6a4875 100644
> >> --- a/arch/arm/mach-omap2/common.h
> >> +++ b/arch/arm/mach-omap2/common.h
> >> @@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params
> >> *sdrc_cs0,
> >> struct omap_sdrc_params *sdrc_cs1);
> >> struct omap2_hsmmc_info;
> >> extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
> >> +extern void omap_dmtimer_init(void);
> >>
> >> #endif /* __ASSEMBLER__ */
> >> #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
> >> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> >> index 13d20c8..e3b9931 100644
> >> --- a/arch/arm/mach-omap2/timer.c
> >> +++ b/arch/arm/mach-omap2/timer.c
> >> @@ -36,6 +36,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include
> >> #include
> >> @@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
> >> }
> >> arch_initcall(omap2_dm_timer_init);
> >>
> >> +static struct property timer_disabled = {
> >> + .name = "status",
> >> + .length = sizeof("disabled"),
> >> + .value = "disabled",
> >> +};
> >> +
> >> +static struct of_device_id omap3_timer_match[] __initdata = {
> >> + { .compatible = "ti,omap3-timer", },
> >> + { }
> >> +};
> >> +
> >> +/**
> >> + * omap_dmtimer_init - initialisation function when device tree is used
> >> + *
> >> + * For secure OMAP3 devices, timers with device type "timer-secure" cannot
> >> + * be used by the kernel as they are reserved. Therefore, to prevent the
> >> + * kernel registering these devices remove them dynamically from the
> >> device
> >> + * tree on boot.
> >> + */
> >> +void __init omap_dmtimer_init(void)
> >> +{
> >> + struct device_node *np;
> >> +
> >> + if (!cpu_is_omap34xx())
> >> + return;
> >> +
> >
> > Sorry for responding so late, but why only omap34xx check here?
> > Isn't this applicable to all omap & non-omap devices?
>
> It is only applicable to omap3 devices as far as omap is concerned.
>
> By non-omap, you are referring to the AMxxx stuff?
>
> Do AMxxx devices even support security (ie. secure boot and have secure
> peripherals)? If not then this will work for AMxxx devices too.
>
Ye
Re: [PATCH v4 4/4] memory: emif: add device tree support to emif driver
On Mon, Aug 13, 2012 at 10:57:06AM +0530, Shilimkar, Santosh wrote:
> Greg,
>
> On Wed, Jul 18, 2012 at 12:14 PM, Shilimkar, Santosh
> wrote:
> > On Tue, Jul 17, 2012 at 11:28 PM, Greg KH
> > wrote:
> >> On Tue, Jul 17, 2012 at 10:37:45PM +0530, Shilimkar, Santosh wrote:
> >>> On Tue, Jul 17, 2012 at 10:06 PM, Greg KH
> >>> wrote:
> >>> > On Mon, Jul 09, 2012 at 07:02:36PM +0530, Shilimkar, Santosh wrote:
> >>> >> Greg,
> >>> >>
> >
> > [..]
> >
> >>> >From 74688a87fd490909e9122bf757c0096480e9fc11 Mon Sep 17 00:00:00 2001
> >>> From: Aneesh V
> >>> Date: Mon, 30 Jan 2012 20:06:30 +0530
> >>> Subject: [PATCH 4/4] memory: emif: add device tree support to emif driver
> >>>
> >>> Device tree support for the EMIF driver. LPDDR2 generic timings
> >>> extraction from device is managed using couple of helper
> >>> functions which can be used by other memory controller
> >>> drivers.
> >>>
> >>> Reviewed-by: Benoit Cousson
> >>> Reviewed-by: Grant Likely
> >>> Tested-by: Lokesh Vutla
> >>> Signed-off-by: Aneesh V
> >>> Signed-off-by: Santosh Shilimkar
> >>> Cc: Greg Kroah-Hartman
> >>> ---
> >>> drivers/memory/Makefile|1 +
> >>> drivers/memory/emif.c | 182
> >>> +++-
> >>> drivers/memory/of_memory.c | 153 +
> >>> drivers/memory/of_memory.h | 36 +
> >>> 4 files changed, 371 insertions(+), 1 deletion(-)
> >>> create mode 100644 drivers/memory/of_memory.c
> >>> create mode 100644 drivers/memory/of_memory.h
> >>>
> >>> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> >>> index 42b3ce9..cd8486b 100644
> >>> --- a/drivers/memory/Makefile
> >>> +++ b/drivers/memory/Makefile
> >>> @@ -2,6 +2,7 @@
> >>> # Makefile for memory devices
> >>> #
> >>>
> >>> +obj-$(CONFIG_OF) += of_memory.o
> >>> obj-$(CONFIG_TI_EMIF)+= emif.o
> >>> obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
> >>> obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
> >>> diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
> >>> index 33a4396..06b4eb7 100644
> >>> --- a/drivers/memory/emif.c
> >>> +++ b/drivers/memory/emif.c
> >>> @@ -18,6 +18,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>> #include
> >>> #include
> >>> @@ -25,6 +26,7 @@
> >>> #include
> >>> #include
> >>> #include "emif.h"
> >>> +#include "of_memory.h"
> >>>
> >>> /**
> >>> * struct emif_data - Per device static data for driver's use
> >>> @@ -49,6 +51,7 @@
> >>> * frequency in effect at the moment)
> >>> * @plat_data: Pointer to saved platform data.
> >>> * @debugfs_root:dentry to the root folder for EMIF in
> >>> debugfs
> >>> + * @np_ddr: Pointer to ddr device tree node
> >>> */
> >>> struct emif_data {
> >>> u8 duplicate;
> >>> @@ -63,6 +66,7 @@ struct emif_data {
> >>> struct emif_regs*curr_regs;
> >>> struct emif_platform_data *plat_data;
> >>> struct dentry *debugfs_root;
> >>> + struct device_node *np_ddr;
> >>> };
> >>>
> >>> static struct emif_data *emif1;
> >>> @@ -1148,6 +1152,168 @@ static int is_custom_config_valid(struct
> >>> emif_custom_configs *cust_cfgs,
> >>> return valid;
> >>> }
> >>>
> >>> +#if defined(CONFIG_OF)
> >>> +static void __init_or_module of_get_custom_configs(struct device_node
> >>> *np_emif,
> >>> + struct emif_data *emif)
> >>
> >> Why can't all of this code be in the of_memory.c file?
> >>
> > Primarily because the parameters are very much specific to EMIF
> > memory controller and won't be of much use for other memory controllers.
> >
> > Currently the information extracted from DT with these function is like:
> > - EMIF controller IP version : EMIF_4D or EMIF_4D5
> > - Which analog phy is integrated : EMIF_ATTILAPHY or EMIF_ATTILAPHY
> > - IP hardware interface: EMIF Low latency port or sys port interface.
> > - EMIF connections - Whether EMIF1 only, EMIF2 only or EMIF1 & EMIF2
> > - Memory connections to EMIF - Same type and size memories or asymmetric
> > - Chip select usage per controller: Whether CS0, CS1, CS0 & CS1
> > - ZQ calibration - Per chip select or enable EMIF dual calibration feature.
> > - Enable/disable EMIF Low power mode and temperature alerts.
> > - EMIF low power mode configuration:
> > - Clock stop, self refresh, Deep power down.
> > - Low power time out values for performance and power mode.
> > - DDR frequency threshold to switch between power and
> > performance settings.
> > - EMIF temperature polling cycle configuration.
> >
> > As you can see these are very specific to the EMIF memory controller and
> > hence
> > I didn't move them to of_memory.c
> >
> Do you have any more comment on this patch? If not, I can go ahead and
> post the refreshed version of the patch.
Ple
Re: [git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver
On 08/16/12 19:34, Sakari Ailus wrote: > Hi Sebastian, > > On Thu, Aug 16, 2012 at 01:21:04PM +0200, Sebastian Reichel wrote: >> Hi, >> It was an requirement back then that this driver needs to be a module as 99% of the N900 owners still don't even know they have this kind of capability on their devices, so it doesn't make sense to keep the module loaded unless the user actually needs it. >>> >>> I don't think that's so important --- currently the vast majority of the >>> N900 users using the mainline kernel compile it themselves. It's more >>> important to have a clean implementation at this point. >> >> I would like to enable this feature for the Debian OMAP kernel, >> which is not only used for N900, but also for Pandaboard, etc. > > Fair enough. Thanks for the info! > > Timo: thinking this a little more, do you think the call is really needed? > AFAIU it doesn't really achieve what it's supposed to, keeping the CPU from > going to sleep. I noticed exactly the same problem you did, it was bad to > the extent irsend failed due to a timeout unless I kept the CPU busy. Yes, that's right. It's not really useful as is. > So I think we can remove the call, which results in two things: the driver > can be built as a module and the platform data does not contain a function > pointer any longer. Yeah, I agree. Although with the original N900 kernel the call did make it work. But the power management implementation was different there too. Maybe the proper fix for the problem is today something different it was back then. If I have time I'll see if I can figure out something.. -Timo -- 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 RESEND 2/4] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
>
>
> On 7/14/2012 3:56 AM, Jon Hunter wrote:
>> OMAP3 devices may or may not have security features enabled. Security enabled
>> devices are known as high-secure (HS) and devices without security are known
>> as
>> general purpose (GP).
>>
>> For OMAP3 devices there are 12 general purpose timers available. On secure
>> devices the 12th timer is reserved for secure usage and so cannot be used by
>> the kernel, where as for a GP device it is available. We can detect the OMAP
>> device type, secure or GP, at runtime via an on-chip register. Today, when
>> not
>> using DT, we do not register the 12th timer as a linux device if the device
>> is
>> secure.
>>
>> When using device tree, device tree is going to register all the timer
>> devices
>> it finds in the device tree blob. To prevent device tree from registering
>> 12th
>> timer on a secure OMAP3 device we can add a status property to the timer
>> binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3
>> device has a property "ti,timer-secure" to indicate that it will not be
>> available on a secure device and so for secure OMAP3 devices, we search for
>> timers with this property and then disable them. Using the
>> prom_add_property()
>> function to dynamically add a property was a recommended approach suggested
>> by
>> Rob Herring [1].
>>
>> I have tested this on an OMAP3 GP device and faking it to pretend to be a
>> secure device to ensure that any timers marked with "ti,timer-secure" are not
>> registered on boot. I have also made sure that all timers are registered as
>> expected on a GP device by default.
>>
>> [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
>>
>> Signed-off-by: Jon Hunter
>> ---
>> arch/arm/mach-omap2/board-generic.c |1 +
>> arch/arm/mach-omap2/common.h|1 +
>> arch/arm/mach-omap2/timer.c | 36
>> +++
>> 3 files changed, 38 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/board-generic.c
>> b/arch/arm/mach-omap2/board-generic.c
>> index 6f93a20..20124d7 100644
>> --- a/arch/arm/mach-omap2/board-generic.c
>> +++ b/arch/arm/mach-omap2/board-generic.c
>> @@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[]
>> __initdata = {
>> static void __init omap_generic_init(void)
>> {
>> omap_sdrc_init(NULL, NULL);
>> +omap_dmtimer_init();
>>
>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>> }
>> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
>> index 1f65b18..d6a4875 100644
>> --- a/arch/arm/mach-omap2/common.h
>> +++ b/arch/arm/mach-omap2/common.h
>> @@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params
>> *sdrc_cs0,
>>struct omap_sdrc_params *sdrc_cs1);
>> struct omap2_hsmmc_info;
>> extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
>> +extern void omap_dmtimer_init(void);
>>
>> #endif /* __ASSEMBLER__ */
>> #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>> index 13d20c8..e3b9931 100644
>> --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -36,6 +36,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
>> }
>> arch_initcall(omap2_dm_timer_init);
>>
>> +static struct property timer_disabled = {
>> +.name = "status",
>> +.length = sizeof("disabled"),
>> +.value = "disabled",
>> +};
>> +
>> +static struct of_device_id omap3_timer_match[] __initdata = {
>> +{ .compatible = "ti,omap3-timer", },
>> +{ }
>> +};
>> +
>> +/**
>> + * omap_dmtimer_init - initialisation function when device tree is used
>> + *
>> + * For secure OMAP3 devices, timers with device type "timer-secure" cannot
>> + * be used by the kernel as they are reserved. Therefore, to prevent the
>> + * kernel registering these devices remove them dynamically from the device
>> + * tree on boot.
>> + */
>> +void __init omap_dmtimer_init(void)
>> +{
>> +struct device_node *np;
>> +
>> +if (!cpu_is_omap34xx())
>> +return;
>> +
>
> Sorry for responding so late, but why only omap34xx check here?
> Isn't this applicable to all omap & non-omap devices?
It is only applicable to omap3 devices as far as omap is concerned.
By non-omap, you are referring to the AMxxx stuff?
Do AMxxx devices even support security (ie. secure boot and have secure
peripherals)? If not then this will work for AMxxx devices too.
Let me know if the changelog is not clear why this is needed for an
omap3 device.
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: [git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver
Hi Sebastian, On Thu, Aug 16, 2012 at 01:21:04PM +0200, Sebastian Reichel wrote: > Hi, > > > > It was an requirement back then that this driver needs to be a module as > > > 99% of the N900 owners still don't even know they have this kind of > > > capability on their devices, so it doesn't make sense to keep the module > > > loaded unless the user actually needs it. > > > > I don't think that's so important --- currently the vast majority of the > > N900 users using the mainline kernel compile it themselves. It's more > > important to have a clean implementation at this point. > > I would like to enable this feature for the Debian OMAP kernel, > which is not only used for N900, but also for Pandaboard, etc. Fair enough. Thanks for the info! Timo: thinking this a little more, do you think the call is really needed? AFAIU it doesn't really achieve what it's supposed to, keeping the CPU from going to sleep. I noticed exactly the same problem you did, it was bad to the extent irsend failed due to a timeout unless I kept the CPU busy. So I think we can remove the call, which results in two things: the driver can be built as a module and the platform data does not contain a function pointer any longer. Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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: Remove the call to platform_set_drvdata(pdev, NULL)
Remove the call of platform_set_drvdata(pdev, NULL) as they are not needed anymore. Signed-off-by: Shubhrajyoti D --- drivers/spi/spi-omap2-mcspi.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index bc47781..84aeaf0 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -1240,7 +1240,6 @@ dma_chnl_free: kfree(mcspi->dma_channels); free_master: kfree(master); - platform_set_drvdata(pdev, NULL); return status; } @@ -1259,7 +1258,6 @@ static int __devexit omap2_mcspi_remove(struct platform_device *pdev) spi_unregister_master(master); kfree(dma_channels); - platform_set_drvdata(pdev, NULL); return 0; } -- 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: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
Hi Vaibhav,
On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
>
>
> On 7/23/2012 8:54 PM, Jon Hunter wrote:
>> Hi Rob,
>>
>> On 07/16/2012 10:56 AM, Jon Hunter wrote:
>>> Hi Rob,
>>>
>>> On 07/13/2012 09:15 PM, Rob Herring wrote:
On 07/13/2012 05:26 PM, Jon Hunter wrote:
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
>
> Add documentation for timer properties specific to OMAP.
>
> For each timer an alias is being added. The purpose for doing this is
> because
> the OMAP dmtimer driver uses an ID to distinguish between the different
> timer
> instances. For example, a timer can be requested by its ID. By adding an
> alias
> for each timer we can then use the function of_alias_get_id() to extract
> the
> ID for each timer from the alias name. The same method is used for the TTY
> serial devices. If it is preferred that such an alias is not added and
> there
> is a better way to pass an ID from device-tree let me know.
I'm not sure this is really a good use of aliases. UARTs use aliases
because it is important that the UART number to tty number is known and
fixed. IIUC, as an example you are picking timer1 because it has
properties X, Y and Z. If so, then you should describe those h/w
properties within the timer nodes so you can pick which timer to use
based on it's h/w properties.
>>>
>>> Thanks for the feedback. What you suggest could definitely work for most
>>> timers. The only item that I would need to resolve here is the handling
>>> of system timers (ie. those used for clockevents and clocksource). These
>>> system timers (for OMAP) are reserved during early boot based upon the
>>> timer ID today and so this is before the actual main timer driver has
>>> been probed and all the attributes of the timers has been read for
>>> device-tree.
>>>
>>> One thought would be to move the reservation of the system timers out of
>>> the kernel and into device-tree itself. Then we query device tree on
>>> start-up to see which we should use. I am wondering if this could be a
>>> better use of alias? For example, say I want to use timer1 as my
>>> clockevent timer and so I could have an alias of ...
>>>
>>> alias {
>>> clockevent_timer = &timer1;
>>> }
>>>
>>> However, I am not sure if this is even correct, because there does not
>>> appear to be an API to search the aliases by name and return the
>>> phandle, just of_alias_get_id(). Alternatively, I could add another
>>> property called "ti,timer-clockevent" that is populated for the timer
>>> used as the clockevent timer.
>>
>> Do you have any inputs on the above? Does it make sense to reserve timer
>> resources for kernel system timers in device-tree?
>>
>
> Hey Jon,
>
> Did we get conclude on this? I haven't got anything further on this
> thread, this may block baseport support for the new devices in omap2
> family, like AM33xx and OMAP5.
Sorry I have been out of the office. However, no update on this so far.
I need to check with Tony if he has any preference for handling this. I
will follow-up with him and keep you posted.
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: [PATCHv7 00/24] I2C big cleanup
On Thu, Aug 16, 2012 at 07:33:31PM +0530, Shubhrajyoti D wrote: > Changes since v1: >- removed tabification on patch 6/17 >- removed dev_err() which was introduced on patch 09/17 > Changes since v2: > - do not set full fifo depth in the RDR interrupt. > - some changelog updates. > - rebase to the Wolfram's tree. > Changes since v3: > - Remove a redundant read of status register > - Read the dev->buf_len variable instead of the register > as the information of the remaining bytes is there. > Changes since v4: > - Ack the arbitration lost. > - Rebase to the i2c-embedded/for-next branch. > Changes since v5: > - Rebase to latest mainline > - Added some more cleanup patches so as have a consolidated series. > Changes since v6: > - Fix comments on setting the pdev to NULL. > - Trivial changelog update > > Tested on omap4sdp and 3430sdp. > > The following changes since commit 3bf671af14d591ede9251acb0085e8017f3705e7: > > Merge branch 'fixes-for-3.6' of > git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds (2012-08-13 > 09:59:04 +0300) > > are available in the git repository at: > > git://gitorious.org/linus-tree/linus-tree.git for_3.6/i2c/big_cleanup A GIT tree, thanks for that! Since the series is quite huge, I'd appreciate it if you could wait for reviews a little bit (a few days) and collect the issues raised there before resending. I know "release early & often", yet the traffic causes some overhead here :) Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PATCHv7 23/24] i2c: omap: sanitize exit path
From: Felipe Balbi
move the goto out label one line down, so that
it can be used when stat is read as zero. All
other exits, can be done with a break statement.
While at that, also break out as soon as we
complete draining IRQ, since at that time
we know we transferred everything there was
to be transferred.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d81189a..3df6f92 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -901,27 +901,26 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
if (!stat) {
/* my work here is done */
- spin_unlock_irqrestore(&dev->lock, flags);
- return IRQ_HANDLED;
+ goto out;
}
dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
if (count++ == 100) {
dev_warn(dev->dev, "Too much work in one IRQ\n");
- goto out;
+ break;
}
if (stat & OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- goto out;
+ break;
}
if (stat & OMAP_I2C_STAT_AL) {
dev_err(dev->dev, "Arbitration lost\n");
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- goto out;
+ break;
}
/*
@@ -934,7 +933,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR |
OMAP_I2C_STAT_ARDY));
- goto out;
+ break;
}
if (stat & OMAP_I2C_STAT_RDR) {
@@ -949,7 +948,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
i2c_omap_errata_i207(dev, stat);
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
- continue;
+ break;
}
if (stat & OMAP_I2C_STAT_RRDY) {
@@ -972,10 +971,10 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
ret = omap_i2c_transmit_data(dev, num_bytes, true);
if (ret < 0)
- goto out;
+ break;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR);
- continue;
+ break;
}
if (stat & OMAP_I2C_STAT_XRDY) {
@@ -987,7 +986,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
ret = omap_i2c_transmit_data(dev, num_bytes, false);
if (ret < 0)
- goto out;
+ break;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XRDY);
continue;
@@ -997,19 +996,20 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
dev_err(dev->dev, "Receive overrun\n");
err |= OMAP_I2C_STAT_ROVR;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
- goto out;
+ break;
}
if (stat & OMAP_I2C_STAT_XUDF) {
dev_err(dev->dev, "Transmit underflow\n");
err |= OMAP_I2C_STAT_XUDF;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
- goto out;
+ break;
}
} while (stat);
-out:
omap_i2c_complete_cmd(dev, err);
+
+out:
spin_unlock_irqrestore(&dev->lock, flags);
return IRQ_HANDLED;
--
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
[PATCHv7 20/24] i2c: omap: switch to threaded IRQ support
From: Felipe Balbi
for OMAP2, we can easily switch over to threaded
IRQs on the I2C driver. This will allow us to
spend less time in hardirq context.
Signed-off-by: Felipe Balbi
[Trivial formating changes]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 43 +++-
1 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f5eafb7..39e5d36 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -176,6 +176,7 @@ enum {
#define I2C_OMAP_ERRATA_I462 (1 << 1)
struct omap_i2c_dev {
+ spinlock_t lock; /* IRQ synchronization */
struct device *dev;
void __iomem*base; /* virtual */
int irq;
@@ -854,9 +855,30 @@ static int omap_i2c_transmit_data(struct omap_i2c_dev
*dev, u8 num_bytes,
}
static irqreturn_t
-omap_i2c_isr(int this_irq, void *dev_id)
+omap_i2c_isr(int irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
+ irqreturn_t ret = IRQ_HANDLED;
+ u16 mask;
+ u16 stat;
+
+ spin_lock(&dev->lock);
+ mask = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+
+ if (stat & mask)
+ ret = IRQ_WAKE_THREAD;
+
+ spin_unlock(&dev->lock);
+
+ return ret;
+}
+
+static irqreturn_t
+omap_i2c_isr_thread(int this_irq, void *dev_id)
+{
+ struct omap_i2c_dev *dev = dev_id;
+ unsigned long flags;
u16 bits;
u16 stat;
int err = 0, count = 0;
@@ -864,6 +886,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (pm_runtime_suspended(dev->dev))
return IRQ_HANDLED;
+ spin_lock_irqsave(&dev->lock, flags);
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
@@ -877,6 +900,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (!stat) {
/* my work here is done */
+ spin_unlock_irqrestore(&dev->lock, flags);
return IRQ_HANDLED;
}
@@ -985,6 +1009,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
out:
omap_i2c_complete_cmd(dev, err);
+ spin_unlock_irqrestore(&dev->lock, flags);
+
return IRQ_HANDLED;
}
@@ -1028,7 +1054,6 @@ omap_i2c_probe(struct platform_device *pdev)
struct omap_i2c_bus_platform_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
- irq_handler_t isr;
int irq;
int r;
@@ -1078,6 +1103,8 @@ omap_i2c_probe(struct platform_device *pdev)
dev->dev = &pdev->dev;
dev->irq = irq;
+ spin_lock_init(&dev->lock);
+
platform_set_drvdata(pdev, dev);
init_completion(&dev->cmd_complete);
@@ -1130,10 +1157,14 @@ omap_i2c_probe(struct platform_device *pdev)
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
- isr = (dev->rev < OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
- omap_i2c_isr;
- r = devm_request_irq(&pdev->dev, dev->irq, isr, IRQF_NO_SUSPEND,
-pdev->name, dev);
+ if (dev->rev < OMAP_I2C_OMAP1_REV_2)
+ r = devm_request_irq(&pdev->dev, dev->irq, omap_i2c_omap1_isr,
+ IRQF_NO_SUSPEND, pdev->name, dev);
+ else
+ r = devm_request_threaded_irq(&pdev->dev, dev->irq,
+ omap_i2c_isr, omap_i2c_isr_thread,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
+ pdev->name, dev);
if (r) {
dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
--
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
[PATCHv7 22/24] i2c: omap: switch over to autosuspend API
From: Felipe Balbi
this helps us reduce unnecessary pm transitions
in case we have another i2c message starting soon.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2d5db56..d81189a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -55,6 +55,9 @@
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
+/* timeout for pm runtime autosuspend */
+#define OMAP_I2C_PM_TIMEOUT1000/* ms */
+
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
enum {
OMAP_I2C_REV_REG = 0,
@@ -645,7 +648,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
omap_i2c_wait_for_bb(dev);
out:
- pm_runtime_put(dev->dev);
+ pm_runtime_mark_last_busy(dev->dev);
+ pm_runtime_put_autosuspend(dev->dev);
return r;
}
@@ -1113,6 +1117,9 @@ omap_i2c_probe(struct platform_device *pdev)
dev->regs = (u8 *)reg_map_ip_v1;
pm_runtime_enable(dev->dev);
+ pm_runtime_set_autosuspend_delay(dev->dev, OMAP_I2C_PM_TIMEOUT);
+ pm_runtime_use_autosuspend(dev->dev);
+
r = pm_runtime_get_sync(dev->dev);
if (IS_ERR_VALUE(r))
goto err_free_mem;
@@ -1190,7 +1197,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
- pm_runtime_put(dev->dev);
+ pm_runtime_mark_last_busy(dev->dev);
+ pm_runtime_put_autosuspend(dev->dev);
return 0;
--
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
[PATCHv7 21/24] i2c: omap: remove unnecessary pm_runtime_suspended check
From: Felipe Balbi
before starting any messages we call pm_runtime_get_sync()
which will make sure that by the time we program a transfer
and our IRQ handler gets called, we're not suspended
anymore.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 39e5d36..2d5db56 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -883,9 +883,6 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
u16 stat;
int err = 0, count = 0;
- if (pm_runtime_suspended(dev->dev))
- return IRQ_HANDLED;
-
spin_lock_irqsave(&dev->lock, flags);
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
--
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
[PATCHv7 13/24] i2c: omap: simplify errata check
From: Felipe Balbi omap_i2c_dev is allocated with kzalloc(), so we need not initialize b_hw to zero. Signed-off-by: Felipe Balbi Signed-off-by: Shubhrajyoti D --- drivers/i2c/busses/i2c-omap.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index fa54d41..80ebcf5 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1095,9 +1095,7 @@ omap_i2c_probe(struct platform_device *pdev) dev->fifo_size = (dev->fifo_size / 2); - if (dev->rev >= OMAP_I2C_REV_ON_3630_4430) - dev->b_hw = 0; /* Disable hardware fixes */ - else + if (dev->rev < OMAP_I2C_REV_ON_3630_4430) dev->b_hw = 1; /* Enable hardware fixes */ /* calculate wakeup latency constraint for MPU */ -- 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
[PATCHv7 24/24] i2c: omap: Prevent NULL pointer dereference in remove
Prevent the NULL pointer access of pdev. The platform_device is anyways deleted so remove platform_set_drvdata(pdev, NULL);. [ 654.961761] Unable to handle kernel NULL pointer dereference at virtual address 0070 [ 654.970611] pgd = df254000 [ 654.973480] [0070] *pgd=9f1da831, *pte=, *ppte= [ 654.980163] Internal error: Oops: 17 [#1] SMP ARM [ 654.985076] Modules linked in: [ 654.988281] CPU: 1Not tainted (3.6.0-rc1-00031-ge547de1-dirty #339) [ 654.995330] PC is at omap_i2c_runtime_resume+0x8/0x148 [ 655.000732] LR is at omap_i2c_runtime_resume+0x8/0x148 Signed-off-by: Shubhrajyoti D --- drivers/i2c/busses/i2c-omap.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 3df6f92..9aefd36 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1207,8 +1207,6 @@ err_unuse_clocks: pm_runtime_put(dev->dev); pm_runtime_disable(&pdev->dev); err_free_mem: - platform_set_drvdata(pdev, NULL); - return r; } @@ -1217,8 +1215,6 @@ static int __devexit omap_i2c_remove(struct platform_device *pdev) struct omap_i2c_dev *dev = platform_get_drvdata(pdev); int ret; - platform_set_drvdata(pdev, NULL); - i2c_del_adapter(&dev->adapter); ret = pm_runtime_get_sync(&pdev->dev); if (IS_ERR_VALUE(ret)) -- 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
[PATCHv7 08/24] i2c: omap: re-factor receive/transmit data loop
From: Felipe Balbi
re-factor the common parts to a separate function,
so that code is easier to read and understand.
No functional changes.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 204
1 files changed, 82 insertions(+), 122 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0067875..d4b6f7d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -752,12 +752,81 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
return 0;
}
+static void omap_i2c_receive_data(struct omap_i2c_dev *dev, u8 num_bytes,
+ bool is_rdr)
+{
+ u16 w;
+
+ while (num_bytes--) {
+ if (!dev->buf_len) {
+ dev_err(dev->dev, "%s without data",
+ is_rdr ? "RDR" : "RRDY");
+ break;
+ }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev->buf++ = w;
+ dev->buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags & OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ *dev->buf++ = w >> 8;
+ dev->buf_len--;
+ }
+ }
+ }
+}
+
+static int omap_i2c_transmit_data(struct omap_i2c_dev *dev, u8 num_bytes,
+ bool is_xdr)
+{
+ u16 w;
+
+ while (num_bytes--) {
+ if (!dev->buf_len) {
+ dev_err(dev->dev, "%s without data",
+ is_xdr ? "XDR" : "XRDY");
+ break;
+ }
+
+ w = *dev->buf++;
+ dev->buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags & OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ w |= *dev->buf++ << 8;
+ dev->buf_len--;
+ }
+ }
+
+ if (dev->errata & I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ if (ret < 0)
+ return ret;
+ }
+
+ omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
+ }
+
+ return 0;
+}
+
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
u16 bits;
- u16 stat, w;
+ u16 stat;
int err, count = 0;
if (pm_runtime_suspended(dev->dev))
@@ -810,30 +879,7 @@ complete:
if (dev->fifo_size)
num_bytes = dev->buf_len;
- while (num_bytes--) {
- if (!dev->buf_len) {
- dev_err(dev->dev,
- "RDR IRQ while no data"
- " requested\n");
- break;
- }
-
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- *dev->buf++ = w;
- dev->buf_len--;
-
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev->flags &
- OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev->buf_len) {
- *dev->buf++ = w >> 8;
- dev->buf_len--;
- }
- }
- }
+ omap_i2c_receive_data(dev, num_bytes, true);
if (dev->errata & I2C_OMAP_ERRATA_I207)
i2c_omap_errata_i207(dev, stat);
@@ -848,77 +894,22 @@ complete:
if (dev->fifo_size)
num_bytes = dev->fifo_size;
- while (num_bytes--) {
- if (!dev->buf_len) {
- dev_err(dev->dev,
- "RRDY IRQ while no data"
- " requested\n");
- break;
- }
-
-
[PATCHv7 16/24] i2c: omap: resize fifos before each message
From: Felipe Balbi
This patch will try to avoid the usage of
draining feature by reconfiguring the FIFO
the start condition of each message based
on the message's size.
By doing that, we will be better utilizing
the FIFO when doing big transfers.
While at that also drop the now unneeded
check for dev->buf_len as we always know
the amount of data to be transmitted.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 83 +
1 files changed, 51 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index b0b1705..dfbf667 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -193,6 +193,7 @@ struct omap_i2c_dev {
u8 *regs;
size_t buf_len;
struct i2c_adapter adapter;
+ u8 threshold;
u8 fifo_size; /* use as flag and value
* fifo_size==0 implies no fifo
* if set, should be trsh+1
@@ -418,13 +419,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
- if (dev->fifo_size) {
- /* Note: setup required fifo size - 1. RTRSH and XTRSH */
- buf = (dev->fifo_size - 1) << 8 | OMAP_I2C_BUF_RXFIF_CLR |
- (dev->fifo_size - 1) | OMAP_I2C_BUF_TXFIF_CLR;
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
- }
-
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
@@ -462,6 +456,45 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
}
+static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
+{
+ u16 buf;
+
+ if (dev->flags & OMAP_I2C_FLAG_NO_FIFO)
+ return;
+
+ /*
+* Set up notification threshold based on message size. We're doing
+* this to try and avoid draining feature as much as possible. Whenever
+* we have big messages to transfer (bigger than our total fifo size)
+* then we might use draining feature to transfer the remaining bytes.
+*/
+
+ dev->threshold = clamp(size, (u8) 1, dev->fifo_size);
+
+ buf = omap_i2c_read_reg(dev, OMAP_I2C_BUF_REG);
+
+ if (is_rx) {
+ /* Clear RX Threshold */
+ buf &= ~(0x3f << 8);
+ buf |= ((dev->threshold - 1) << 8) | OMAP_I2C_BUF_RXFIF_CLR;
+ } else {
+ /* Clear TX Threshold */
+ buf &= ~0x3f;
+ buf |= (dev->threshold - 1) | OMAP_I2C_BUF_TXFIF_CLR;
+ }
+
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
+
+ if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
+ dev->b_hw = 1; /* Enable hardware fixes */
+
+ /* calculate wakeup latency constraint for MPU */
+ if (dev->set_mpu_wkup_lat != NULL)
+ dev->latency = (100 * dev->threshold) /
+ (1000 * dev->speed / 8);
+}
+
/*
* Low level master read/write transaction.
*/
@@ -478,6 +511,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (msg->len == 0)
return -EINVAL;
+ dev->receiver = !!(msg->flags & I2C_M_RD);
+ omap_i2c_resize_fifo(dev, msg->len, dev->receiver);
+
omap_i2c_write_reg(dev, OMAP_I2C_SA_REG, msg->addr);
/* REVISIT: Could the STB bit of I2C_CON be used with probing? */
@@ -493,7 +529,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
INIT_COMPLETION(dev->cmd_complete);
dev->cmd_err = 0;
- dev->receiver = !!(msg->flags & I2C_M_RD);
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT;
@@ -760,12 +795,6 @@ static void omap_i2c_receive_data(struct omap_i2c_dev
*dev, u8 num_bytes,
u16 w;
while (num_bytes--) {
- if (!dev->buf_len) {
- dev_err(dev->dev, "%s without data",
- is_rdr ? "RDR" : "RRDY");
- break;
- }
-
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev->buf++ = w;
dev->buf_len--;
@@ -775,10 +804,8 @@ static void omap_i2c_receive_data(struct omap_i2c_dev
*dev, u8 num_bytes,
* omap4 is 8 bit wide
*/
if (dev->flags & OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev->buf_len) {
- *dev->buf++ = w >> 8;
- dev->buf_len--;
- }
+ *dev->buf++ = w >> 8;
+ dev->buf_len--;
}
[PATCHv7 09/24] i2c: omap: switch over to do {} while loop
From: Felipe Balbi
this will make sure that we execute at least once.
No functional changes otherwise.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d4b6f7d..8b80799 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -827,20 +827,28 @@ omap_i2c_isr(int this_irq, void *dev_id)
struct omap_i2c_dev *dev = dev_id;
u16 bits;
u16 stat;
- int err, count = 0;
+ int err = 0, count = 0;
if (pm_runtime_suspended(dev->dev))
return IRQ_NONE;
- bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- while ((stat = (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG))) & bits) {
+ do {
+ bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ stat &= bits;
+
+ if (!stat) {
+ /* my work here is done */
+ return IRQ_HANDLED;
+ }
+
dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
if (count++ == 100) {
dev_warn(dev->dev, "Too much work in one IRQ\n");
- break;
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
- err = 0;
complete:
/*
* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
@@ -940,7 +948,7 @@ complete:
dev_err(dev->dev, "Transmit underflow\n");
dev->cmd_err |= OMAP_I2C_STAT_XUDF;
}
- }
+ } while (stat);
return count ? IRQ_HANDLED : IRQ_NONE;
}
--
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
[PATCHv7 04/24] i2c: omap: add blank lines
From: Felipe Balbi
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 81ef0a7..dbc5a3c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -786,6 +786,7 @@ complete:
dev_err(dev->dev, "Arbitration lost\n");
err |= OMAP_I2C_STAT_AL;
}
+
/*
* ProDB0017052: Clear ARDY bit twice
*/
@@ -798,6 +799,7 @@ complete:
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
+
if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
@@ -844,6 +846,7 @@ complete:
stat & (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
continue;
}
+
if (stat & (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
u8 num_bytes = 1;
if (dev->fifo_size) {
@@ -891,10 +894,12 @@ complete:
stat & (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
continue;
}
+
if (stat & OMAP_I2C_STAT_ROVR) {
dev_err(dev->dev, "Receive overrun\n");
dev->cmd_err |= OMAP_I2C_STAT_ROVR;
}
+
if (stat & OMAP_I2C_STAT_XUDF) {
dev_err(dev->dev, "Transmit underflow\n");
dev->cmd_err |= OMAP_I2C_STAT_XUDF;
--
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
[PATCHv7 02/24] i2c: omap: simplify num_bytes handling
From: Felipe Balbi
trivial patch, no functional changes
If the fifo is disabled or fifo_size is 0 the num_bytes
is set to 1. Else it is set to fifo_size or in case of a
draining interrupt the remaining bytes in the buff stat.
So the zero check is redundant and can be safely optimised.
Signed-off-by: Felipe Balbi
Reviewed-by : Santosh Shilimkar
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6449383..9b003a3 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -812,8 +812,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
>> 8) & 0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
if (dev->buf_len) {
*dev->buf++ = w;
@@ -855,8 +854,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
& 0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = 0;
if (dev->buf_len) {
w = *dev->buf++;
--
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
[PATCHv7 07/24] i2c: omap: improve i462 errata handling
From: Felipe Balbi
Make it not depend on ISR's local variables
in order to make it easier to re-factor the
transmit data loop.
Also since we are waiting for XUDF(Transmitter underflow) just before
writing data lets not flag the underflow.
This is anyways going to go once we write
the data.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 43
1 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 139602f..0067875 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -725,27 +725,30 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev)
{
unsigned long timeout = 1;
+ u16 stat;
- while (--timeout && !(*stat & OMAP_I2C_STAT_XUDF)) {
- if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
+ do {
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ if (stat & OMAP_I2C_STAT_XUDF)
+ break;
+
+ if (stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
- return -ETIMEDOUT;
+ return -EIO;
}
cpu_relax();
- *stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
+ } while (--timeout);
if (!timeout) {
dev_err(dev->dev, "timeout waiting on XUDF bit\n");
return 0;
}
- *err |= OMAP_I2C_STAT_XUDF;
return 0;
}
@@ -903,9 +906,16 @@ complete:
}
}
- if ((dev->errata & I2C_OMAP_ERRATA_I462) &&
- errata_omap3_i462(dev, &stat, &err))
- goto complete;
+ if (dev->errata & I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ stat = omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG);
+
+ if (ret < 0)
+ goto complete;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
@@ -943,9 +953,16 @@ complete:
}
}
- if ((dev->errata & I2C_OMAP_ERRATA_I462) &&
- errata_omap3_i462(dev, &stat, &err))
- goto complete;
+ if (dev->errata & I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ stat = omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG);
+
+ if (ret < 0)
+ goto complete;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
--
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
[PATCHv7 05/24] i2c: omap: simplify omap_i2c_ack_stat()
From: Felipe Balbi
stat & BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing "stat &" from
all omap_i2c_ack_stat() calls.
Code snippet (extremely simplified):
if (stat & NACK) {
...
omap_i2c_ack_stat(dev, stat & NACK);
}
if (stat & RDR) {
...
omap_i2c_ack_stat(dev, stat & RDR);
}
and so on. The tricky place is only WRT errata handling, for example:
if (*stat & (NACK | AL)) {
omap_i2c_ack_stat(dev, *stat & (XRDY | XDR));
...
}
but in this case, the errata says we must clear XRDY and XDR if that
errata triggers, so if they just got enabled or not, it doesn't matter.
Another tricky place is RDR | RRDY (likewise for XDR | XRDY):
if (stat & (RDR | RRDY)) {
...
omap_i2c_ack_stat(dev, stat & (RDR | RRDY));
}
again here there will be no issues because those IRQs never fire
simultaneously and one will only after after we have handled the
previous, that's because the same FIFO is used anyway and we won't shift
data into FIFO until we tell the IP "hey, I'm done with the FIFO, you
can shift more data"
Signed-off-by: Felipe Balbi
Reviewed-by : Santosh Shilimkar
[Added the explaination from the discurssion to the commit logs]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dbc5a3c..8009095 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -731,7 +731,7 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev, u16
*stat, int *err)
while (--timeout && !(*stat & OMAP_I2C_STAT_XUDF)) {
if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, *stat & (OMAP_I2C_STAT_XRDY |
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
return -ETIMEDOUT;
}
@@ -792,10 +792,11 @@ complete:
*/
if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, stat &
- (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
- OMAP_I2C_STAT_ARDY));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR |
+ OMAP_I2C_STAT_ARDY));
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
@@ -842,8 +843,8 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev,
- stat & (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR));
continue;
}
@@ -890,8 +891,8 @@ complete:
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
- omap_i2c_ack_stat(dev,
- stat & (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR));
continue;
}
--
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
[PATCHv7 03/24] i2c: omap: decrease indentation level on data handling
From: Felipe Balbi
The patch intends to decrease the indentation level on the
data handling
by using the fact that else of if (dev->buf_len) is same as
if (!dev->buf_len)
if (dev->buf_len) {
aaa;
} else {
bbb;
break;
}
to
if (!dev->buf_len) {
bbb;
break;
}
aaa;
Hence no functional changes.
Signed-off-by: Felipe Balbi
Reviewed-by : Santosh Shilimkar
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 63 -
1 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9b003a3..81ef0a7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -813,22 +813,7 @@ complete:
>> 8) & 0x3F;
}
while (num_bytes--) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- if (dev->buf_len) {
- *dev->buf++ = w;
- dev->buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev->flags &
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev->buf_len) {
- *dev->buf++ = w >> 8;
- dev->buf_len--;
- }
- }
- } else {
+ if (!dev->buf_len) {
if (stat & OMAP_I2C_STAT_RRDY)
dev_err(dev->dev,
"RRDY IRQ while no data"
@@ -839,6 +824,21 @@ complete:
" requested\n");
break;
}
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev->buf++ = w;
+ dev->buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags &
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ *dev->buf++ = w >> 8;
+ dev->buf_len--;
+ }
+ }
}
omap_i2c_ack_stat(dev,
stat & (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
@@ -855,22 +855,7 @@ complete:
& 0x3F;
}
while (num_bytes--) {
- w = 0;
- if (dev->buf_len) {
- w = *dev->buf++;
- dev->buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev->flags &
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev->buf_len) {
- w |= *dev->buf++ << 8;
- dev->buf_len--;
- }
- }
- } else {
+ if (!dev->buf_len) {
if (stat & OMAP_I2C_STAT_XRDY)
dev_err(dev->dev,
"XRDY IRQ while no "
@@ -882,6 +867,20 @@ complete:
break;
}
+ w = *dev->buf++;
+ dev->buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+
[PATCHv7 17/24] i2c: omap: get rid of the "complete" label
From: Felipe Balbi
we can ack stat and complete the command from
the errata handling itself.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dfbf667..dfdcc2b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -775,6 +775,17 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
if (stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ if (stat & OMAP_I2C_STAT_NACK) {
+ dev->cmd_err |= OMAP_I2C_STAT_NACK;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ }
+
+ if (stat & OMAP_I2C_STAT_AL) {
+ dev_err(dev->dev, "Arbitration lost\n");
+ dev->cmd_err |= OMAP_I2C_STAT_AL;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ }
+
return -EIO;
}
@@ -875,7 +886,6 @@ omap_i2c_isr(int this_irq, void *dev_id)
goto out;
}
-complete:
if (stat & OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
@@ -938,7 +948,7 @@ complete:
ret = omap_i2c_transmit_data(dev, num_bytes, true);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret < 0)
- goto complete;
+ goto out;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR);
continue;
@@ -954,7 +964,7 @@ complete:
ret = omap_i2c_transmit_data(dev, num_bytes, false);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret < 0)
- goto complete;
+ goto out;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XRDY);
continue;
--
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
[PATCHv7 11/24] i2c: omap: switch to platform_get_irq()
From: Felipe Balbi
that's a nice helper from drivers core which
will give us the exact IRQ number, instead
of a pointer to an IRQ resource.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0adbfb1..e9907b5 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -993,11 +993,12 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq;
+ struct resource *mem;
struct omap_i2c_bus_platform_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
irq_handler_t isr;
+ int irq;
int r;
/* NOTE: driver uses the static register mapping */
@@ -1006,10 +1007,11 @@ omap_i2c_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "no mem resource?\n");
return -ENODEV;
}
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!irq) {
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
dev_err(&pdev->dev, "no irq resource?\n");
- return -ENODEV;
+ return irq;
}
dev = devm_kzalloc(&pdev->dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
@@ -1043,7 +1045,7 @@ omap_i2c_probe(struct platform_device *pdev)
}
dev->dev = &pdev->dev;
- dev->irq = irq->start;
+ dev->irq = irq;
platform_set_drvdata(pdev, dev);
init_completion(&dev->cmd_complete);
--
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
[PATCHv7 01/24] i2c: omap: switch to devm_* API
From: Felipe Balbi
that helps deleting some boiler plate code
and lets driver-core manage our resources
for us.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 41 -
1 files changed, 12 insertions(+), 29 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6849635..6449383 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -943,7 +943,7 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq, *ioarea;
+ struct resource *mem, *irq;
struct omap_i2c_bus_platform_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
@@ -962,17 +962,16 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem->start, resource_size(mem),
- pdev->name);
- if (!ioarea) {
- dev_err(&pdev->dev, "I2C region already claimed\n");
- return -EBUSY;
+ dev = devm_kzalloc(&pdev->dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(&pdev->dev, "Menory allocation failed\n");
+ return -ENOMEM;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
- if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev->base = devm_request_and_ioremap(&pdev->dev, mem);
+ if (!dev->base) {
+ dev_err(&pdev->dev, "I2C region already claimed\n");
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), &pdev->dev);
@@ -995,11 +994,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev->dev = &pdev->dev;
dev->irq = irq->start;
- dev->base = ioremap(mem->start, resource_size(mem));
- if (!dev->base) {
- r = -ENOMEM;
- goto err_free_mem;
- }
platform_set_drvdata(pdev, dev);
init_completion(&dev->cmd_complete);
@@ -1057,7 +1051,8 @@ omap_i2c_probe(struct platform_device *pdev)
isr = (dev->rev < OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
omap_i2c_isr;
- r = request_irq(dev->irq, isr, IRQF_NO_SUSPEND, pdev->name, dev);
+ r = devm_request_irq(&pdev->dev, dev->irq, isr, IRQF_NO_SUSPEND,
+pdev->name, dev);
if (r) {
dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
@@ -1081,7 +1076,7 @@ omap_i2c_probe(struct platform_device *pdev)
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev->dev, "failure adding adapter\n");
- goto err_free_irq;
+ goto err_unuse_clocks;
}
of_i2c_register_devices(adap);
@@ -1090,18 +1085,12 @@ omap_i2c_probe(struct platform_device *pdev)
return 0;
-err_free_irq:
- free_irq(dev->irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev->dev);
- iounmap(dev->base);
pm_runtime_disable(&pdev->dev);
err_free_mem:
platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem->start, resource_size(mem));
return r;
}
@@ -1109,12 +1098,10 @@ err_release_region:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
int ret;
platform_set_drvdata(pdev, NULL);
- free_irq(dev->irq, dev);
i2c_del_adapter(&dev->adapter);
ret = pm_runtime_get_sync(&pdev->dev);
if (IS_ERR_VALUE(ret))
@@ -1123,10 +1110,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(&pdev->dev);
pm_runtime_disable(&pdev->dev);
- iounmap(dev->base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem->start, resource_size(mem));
return 0;
}
--
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
[PATCHv7 15/24] i2c: omap: simplify IRQ exit path
From: Felipe Balbi
instead of having multiple return points, use
a goto statement to make that clearer.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index eb6898b..b0b1705 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -853,24 +853,21 @@ omap_i2c_isr(int this_irq, void *dev_id)
dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
if (count++ == 100) {
dev_warn(dev->dev, "Too much work in one IRQ\n");
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
complete:
if (stat & OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat & OMAP_I2C_STAT_AL) {
dev_err(dev->dev, "Arbitration lost\n");
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
/*
@@ -883,8 +880,7 @@ complete:
OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR |
OMAP_I2C_STAT_ARDY));
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat & OMAP_I2C_STAT_RDR) {
@@ -949,19 +945,19 @@ complete:
dev_err(dev->dev, "Receive overrun\n");
err |= OMAP_I2C_STAT_ROVR;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat & OMAP_I2C_STAT_XUDF) {
dev_err(dev->dev, "Transmit underflow\n");
err |= OMAP_I2C_STAT_XUDF;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
} while (stat);
+out:
+ omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
--
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
[PATCHv7 06/24] i2c: omap: split out [XR]DR and [XR]RDY
From: Felipe Balbi
While they do pretty much the same thing, there
are a few peculiarities. Specially WRT erratas,
it's best to split those out and re-factor the
read/write loop to another function which both
cases call.
This last part will be done on another patch.
While at that, also avoid an unncessary register
read since dev->fifo_len will always contain the
correct amount of data to be transferred.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 126 ++---
1 files changed, 92 insertions(+), 34 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 8009095..139602f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -801,36 +801,62 @@ complete:
return IRQ_HANDLED;
}
- if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
+ if (stat & OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
+ if (dev->fifo_size)
+ num_bytes = dev->buf_len;
+
+ while (num_bytes--) {
+ if (!dev->buf_len) {
+ dev_err(dev->dev,
+ "RDR IRQ while no data"
+ " requested\n");
+ break;
+ }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev->buf++ = w;
+ dev->buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags &
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ *dev->buf++ = w >> 8;
+ dev->buf_len--;
+ }
+ }
+ }
+
if (dev->errata & I2C_OMAP_ERRATA_I207)
i2c_omap_errata_i207(dev, stat);
- if (dev->fifo_size) {
- if (stat & OMAP_I2C_STAT_RRDY)
- num_bytes = dev->fifo_size;
- else/* read RXSTAT on RDR interrupt */
- num_bytes = (omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG)
- >> 8) & 0x3F;
- }
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+ continue;
+ }
+
+ if (stat & OMAP_I2C_STAT_RRDY) {
+ u8 num_bytes = 1;
+
+ if (dev->fifo_size)
+ num_bytes = dev->fifo_size;
+
while (num_bytes--) {
if (!dev->buf_len) {
- if (stat & OMAP_I2C_STAT_RRDY)
- dev_err(dev->dev,
+ dev_err(dev->dev,
"RRDY IRQ while no data"
- " requested\n");
- if (stat & OMAP_I2C_STAT_RDR)
- dev_err(dev->dev,
- "RDR IRQ while no data"
- " requested\n");
+ " requested\n");
break;
}
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev->buf++ = w;
dev->buf_len--;
+
/*
* Data reg in 2430, omap3 and
* omap4 is 8 bit wide
@@ -843,36 +869,68 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
- OMAP_I2C_STAT_RDR));
+
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RRDY);
continue;
}
- if (stat & (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
+
[PATCHv7 12/24] i2c: omap: bus: add a receiver flag
From: Felipe Balbi
that way we can ignore TX IRQs while in receiver
mode and ignore RX IRQs while in transmitter mode.
Signed-off-by: Felipe Balbi
[Remove unnecessary braces]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e9907b5..fa54d41 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -199,6 +199,7 @@ struct omap_i2c_dev {
*/
u8 rev;
unsignedb_hw:1; /* bad h/w fixes */
+ unsignedreceiver:1; /* true when we're in receiver
mode */
u16 iestate;/* Saved interrupt register */
u16 pscstate;
u16 scllstate;
@@ -492,6 +493,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
INIT_COMPLETION(dev->cmd_complete);
dev->cmd_err = 0;
+ dev->receiver = !!(msg->flags & I2C_M_RD);
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT;
@@ -837,6 +839,12 @@ omap_i2c_isr(int this_irq, void *dev_id)
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
stat &= bits;
+ /* If we're in receiver mode, ignore XDR/XRDY */
+ if (dev->receiver)
+ stat &= ~(OMAP_I2C_STAT_XDR | OMAP_I2C_STAT_XRDY);
+ else
+ stat &= ~(OMAP_I2C_STAT_RDR | OMAP_I2C_STAT_RRDY);
+
if (!stat) {
/* my work here is done */
return IRQ_HANDLED;
--
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
[PATCHv7 00/24] I2C big cleanup
Changes since v1:
- removed tabification on patch 6/17
- removed dev_err() which was introduced on patch 09/17
Changes since v2:
- do not set full fifo depth in the RDR interrupt.
- some changelog updates.
- rebase to the Wolfram's tree.
Changes since v3:
- Remove a redundant read of status register
- Read the dev->buf_len variable instead of the register
as the information of the remaining bytes is there.
Changes since v4:
- Ack the arbitration lost.
- Rebase to the i2c-embedded/for-next branch.
Changes since v5:
- Rebase to latest mainline
- Added some more cleanup patches so as have a consolidated series.
Changes since v6:
- Fix comments on setting the pdev to NULL.
- Trivial changelog update
Tested on omap4sdp and 3430sdp.
The following changes since commit 3bf671af14d591ede9251acb0085e8017f3705e7:
Merge branch 'fixes-for-3.6' of
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds (2012-08-13
09:59:04 +0300)
are available in the git repository at:
git://gitorious.org/linus-tree/linus-tree.git for_3.6/i2c/big_cleanup
Felipe Balbi (22):
i2c: omap: switch to devm_* API
i2c: omap: simplify num_bytes handling
i2c: omap: decrease indentation level on data handling
i2c: omap: add blank lines
i2c: omap: simplify omap_i2c_ack_stat()
i2c: omap: split out [XR]DR and [XR]RDY
i2c: omap: improve i462 errata handling
i2c: omap: re-factor receive/transmit data loop
i2c: omap: switch over to do {} while loop
i2c: omap: ack IRQ in parts
i2c: omap: switch to platform_get_irq()
i2c: omap: bus: add a receiver flag
i2c: omap: simplify errata check
i2c: omap: always return IRQ_HANDLED
i2c: omap: simplify IRQ exit path
i2c: omap: resize fifos before each message
i2c: omap: get rid of the "complete" label
i2c: omap: always return IRQ_HANDLED
i2c: omap: switch to threaded IRQ support
i2c: omap: remove unnecessary pm_runtime_suspended check
i2c: omap: switch over to autosuspend API
i2c: omap: sanitize exit path
Shubhrajyoti D (2):
i2c: omap: remove redundant status read
i2c: omap: Prevent NULL pointer dereference in remove
drivers/i2c/busses/i2c-omap.c | 446 +
1 files changed, 271 insertions(+), 175 deletions(-)
--
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
[PATCHv7 19/24] i2c: omap: always return IRQ_HANDLED
From: Felipe Balbi
even if our clocks are disabled, we still
handled the IRQ, so we should return IRQ_HANDLED.
Signed-off-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2dd2301..f5eafb7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -862,7 +862,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
int err = 0, count = 0;
if (pm_runtime_suspended(dev->dev))
- return IRQ_NONE;
+ return IRQ_HANDLED;
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
--
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
[PATCHv7 18/24] i2c: omap: remove redundant status read
Remove the redundant read of the status register. Signed-off-by: Shubhrajyoti D --- drivers/i2c/busses/i2c-omap.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index dfdcc2b..2dd2301 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -946,7 +946,6 @@ omap_i2c_isr(int this_irq, void *dev_id) num_bytes = dev->buf_len; ret = omap_i2c_transmit_data(dev, num_bytes, true); - stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); if (ret < 0) goto out; @@ -962,7 +961,6 @@ omap_i2c_isr(int this_irq, void *dev_id) num_bytes = dev->threshold; ret = omap_i2c_transmit_data(dev, num_bytes, false); - stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); if (ret < 0) goto out; -- 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
[PATCHv7 10/24] i2c: omap: ack IRQ in parts
From: Felipe Balbi
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
Signed-off-by: Felipe Balbi
[Ack the stat OMAP_I2C_STAT_AL in case of arbitration lost]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 8b80799..0adbfb1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -850,21 +850,19 @@ omap_i2c_isr(int this_irq, void *dev_id)
}
complete:
- /*
-* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
-* acked after the data operation is complete.
-* Ref: TRM SWPU114Q Figure 18-31
-*/
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat &
- ~(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
-
- if (stat & OMAP_I2C_STAT_NACK)
+ if (stat & OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
+ }
if (stat & OMAP_I2C_STAT_AL) {
dev_err(dev->dev, "Arbitration lost\n");
err |= OMAP_I2C_STAT_AL;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
/*
@@ -941,12 +939,18 @@ complete:
if (stat & OMAP_I2C_STAT_ROVR) {
dev_err(dev->dev, "Receive overrun\n");
- dev->cmd_err |= OMAP_I2C_STAT_ROVR;
+ err |= OMAP_I2C_STAT_ROVR;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
if (stat & OMAP_I2C_STAT_XUDF) {
dev_err(dev->dev, "Transmit underflow\n");
- dev->cmd_err |= OMAP_I2C_STAT_XUDF;
+ err |= OMAP_I2C_STAT_XUDF;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
} while (stat);
--
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
[PATCHv7 14/24] i2c: omap: always return IRQ_HANDLED
From: Felipe Balbi
Always return IRQ_HANDLED otherwise we could get our IRQ line disabled due
to many spurious IRQs.
Signed-off-by: Felipe Balbi
[Trivial changes to commitlogs]
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 80ebcf5..eb6898b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -962,7 +962,7 @@ complete:
}
} while (stat);
- return count ? IRQ_HANDLED : IRQ_NONE;
+ return IRQ_HANDLED;
}
static const struct i2c_algorithm omap_i2c_algo = {
--
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 3/4] arm/dts: Add tps65910 regulator DT data to am335x-evm.dts
On Thu, Aug 16, 2012 at 01:22:27PM +, AnilKumar, Chimata wrote: > But problem here is single input supply battery/main is not sufficient. What makes you say this? > pmic->desc[i].supply_name = info->vin_name; > with this assignment regulator core searches for exact supply name vcc1 or > vcc2 etc if there are no matches then it will not register any regulators. Why does this mean you need multiple regulators? A single regulator can of course supply multiple devices. -- 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 v3 9/9] ASoC: omap-mcbsp: Add device tree bindings
Device tree support for McBSP modules on OMAP2+ SoC.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/sound/omap-mcbsp.txt | 45 +
sound/soc/omap/omap-mcbsp.c| 66 +++-
2 files changed, 110 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/omap-mcbsp.txt
diff --git a/Documentation/devicetree/bindings/sound/omap-mcbsp.txt
b/Documentation/devicetree/bindings/sound/omap-mcbsp.txt
new file mode 100644
index 000..447cb13
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/omap-mcbsp.txt
@@ -0,0 +1,45 @@
+* Texas Instruments OMAP2+ McBSP module
+
+Required properties:
+- compatible: "ti,omap2420-mcbsp" for McBSP on OMAP2420
+ "ti,omap2430-mcbsp" for McBSP on OMAP2430
+ "ti,omap3-mcbsp" for McBSP on OMAP3
+ "ti,omap4-mcbsp" for McBSP on OMAP4 and newer SoC
+- reg: Register location and size, for OMAP4+ as an array:
+ ,
+ ;
+- interrupts: Interrupt numbers for the McBSP port, as an array in case the
+ McBSP IP have more interrupt lines:
+ ,
+ ,
+ ;
+- interrupt-parent: The parent interrupt controller
+- ti,buffer-size: Size of the FIFO on the port (OMAP2430 and newer SoC)
+- ti,hwmods: Name of the hwmod associated to the McBSP port
+
+Sidetone support for OMAP3 McBSP2 and 3 ports:
+- sidetone { }: Within this section the following parameters are required:
+- reg: Register location and size for the ST block
+- interrupts: The interrupt number for the ST block
+- interrupt-parent: The parent interrupt controller for the ST block
+
+Example:
+
+mcbsp2: mcbsp@49022000 {
+ compatible = "ti,omap3-mcbsp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x49022000 0xff>;
+ interrupts = <0 17 0x4>, /* OCP compliant interrup */
+<0 62 0x4>, /* TX interrup */
+<0 63 0x4>; /* RX interrup */
+ interrupt-parent = <&intc>;
+ ti,buffer-size = <1280>;
+ ti,hwmods = "mcbsp2";
+
+ sidetone {
+ reg = <0x49028000 0xff>;
+ interrupts = <0 4 0x4>;
+ interrupt-parent = <&intc>;
+ };
+};
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index b9770ee..2e1750e 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -737,13 +739,74 @@ int omap_mcbsp_st_add_controls(struct snd_soc_pcm_runtime
*rtd)
}
EXPORT_SYMBOL_GPL(omap_mcbsp_st_add_controls);
+static struct omap_mcbsp_platform_data omap2420_pdata = {
+ .reg_step = 4,
+ .reg_size = 2,
+};
+
+static struct omap_mcbsp_platform_data omap2430_pdata = {
+ .reg_step = 4,
+ .reg_size = 4,
+ .has_ccr = true,
+};
+
+static struct omap_mcbsp_platform_data omap3_pdata = {
+ .reg_step = 4,
+ .reg_size = 4,
+ .has_ccr = true,
+ .has_wakeup = true,
+};
+
+static struct omap_mcbsp_platform_data omap4_pdata = {
+ .reg_step = 4,
+ .reg_size = 4,
+ .has_ccr = true,
+ .has_wakeup = true,
+};
+
+static const struct of_device_id omap_mcbsp_of_match[] = {
+ {
+ .compatible = "ti,omap2420-mcbsp",
+ .data = &omap2420_pdata,
+ },
+ {
+ .compatible = "ti,omap2430-mcbsp",
+ .data = &omap2430_pdata,
+ },
+ {
+ .compatible = "ti,omap3-mcbsp",
+ .data = &omap3_pdata,
+ },
+ {
+ .compatible = "ti,omap4-mcbsp",
+ .data = &omap4_pdata,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, omap_mcbsp_of_match);
+
static __devinit int asoc_mcbsp_probe(struct platform_device *pdev)
{
struct omap_mcbsp_platform_data *pdata = dev_get_platdata(&pdev->dev);
struct omap_mcbsp *mcbsp;
+ const struct of_device_id *match;
int ret;
- if (!pdata) {
+ match = of_match_device(omap_mcbsp_of_match, &pdev->dev);
+ if (match) {
+ struct device_node *node = pdev->dev.of_node;
+ int buffer_size;
+
+ pdata = devm_kzalloc(&pdev->dev,
+sizeof(struct omap_mcbsp_platform_data),
+GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ memcpy(pdata, match->data, sizeof(*pdata));
+ if (!of_property_read_u32(node, "ti,buffer-size", &buffer_size))
+ pdata->buffer_size = buffer_size;
+ } else if (!pdata) {
dev_err(&pdev->dev, "missing platform data.\n");
return -EINVAL;
}
@@ -785,6 +848,7 @@ static struct platform_driver asoc_mcbsp_driver = {
.driver = {
.name = "omap-mcbsp",
.owner = TH
[PATCH v3 8/9] ARM: OMAP2+: McBSP: Do not create legacy devices when booting with DT data
Only create the devices in a legacy way if we do not have the DT data.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/mcbsp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 660e00b..d57a357 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -113,7 +114,8 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh,
void *unused)
static int __init omap2_mcbsp_init(void)
{
- omap_hwmod_for_each_by_class("mcbsp", omap_init_mcbsp, NULL);
+ if (!of_have_populated_dt())
+ omap_hwmod_for_each_by_class("mcbsp", omap_init_mcbsp, NULL);
return 0;
}
--
1.7.8.6
--
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 v3 7/9] ASoC: omap-mcbsp: Remove cpu_is_omap* checks from the code
We can use the has_ccr flag to replace the cpu_is_omap* checks.
This provides future proof implementation and we do not need to update the
code if new OMAP revision starts to use the McBSP driver.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
sound/soc/omap/omap-mcbsp.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 5061594..b9770ee 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -398,12 +398,14 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
/* Generic McBSP register settings */
regs->spcr2 |= XINTM(3) | FREE;
regs->spcr1 |= RINTM(3);
- /* RFIG and XFIG are not defined in 34xx */
- if (!cpu_is_omap34xx() && !cpu_is_omap44xx()) {
+ /* RFIG and XFIG are not defined in 2430 and on OMAP3+ */
+ if (!mcbsp->pdata->has_ccr) {
regs->rcr2 |= RFIG;
regs->xcr2 |= XFIG;
}
- if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) {
+
+ /* Configure XCCR/RCCR only for revisions which have ccr registers */
+ if (mcbsp->pdata->has_ccr) {
regs->xccr = DXENDLY(1) | XDMAEN | XDISABLE;
regs->rccr = RFULL_CYCLE | RDMAEN | RDISABLE;
}
--
1.7.8.6
--
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 v3 6/9] ASoC: omap-mcbsp: Remove unused defines
NUM_LINKS is no longer in use by the code.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
sound/soc/omap/omap-mcbsp.h | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index baebcee..ba8386a 100644
--- a/sound/soc/omap/omap-mcbsp.h
+++ b/sound/soc/omap/omap-mcbsp.h
@@ -39,22 +39,6 @@ enum omap_mcbsp_div {
OMAP_MCBSP_CLKGDV, /* Sample rate generator divider */
};
-#if defined(CONFIG_SOC_OMAP2420)
-#define NUM_LINKS 2
-#endif
-#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
-#undef NUM_LINKS
-#define NUM_LINKS 3
-#endif
-#if defined(CONFIG_ARCH_OMAP4)
-#undef NUM_LINKS
-#define NUM_LINKS 4
-#endif
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_OMAP2430)
-#undef NUM_LINKS
-#define NUM_LINKS 5
-#endif
-
int omap_mcbsp_st_add_controls(struct snd_soc_pcm_runtime *rtd);
#endif
--
1.7.8.6
--
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 v3 5/9] ARM/ASoC: omap-mcbsp: Remove CLKR/FSR mux configuration code
Remove the feature to configure the CLKR/FSR mux on McBSP port with 6pin
configuration.
When moving to devicetree these callback can no longer be used in a clean
way anymore.
If a board require to change the 6pin port to work in 4pin setup it needs
to set up the mux in the board file.
For OMAP2/3:
u32 devconf0;
/* McBSP1 CLKR/FSR signal to be connected to CLKX/FSX pin */
devconf0 = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
devconf0 |= OMAP2_MCBSP1_CLKR_MASK | OMAP2_MCBSP1_FSR_MASK;
omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
For OMAP4:
u32 mcbsp_pad;
/* McBSP4 CLKR/FSR signal to be connected to CLKX/FSX pin */
mcbsp_pad = omap4_ctrl_pad_readl(OMAP2_CONTROL_DEVCONF0);
mcbsp_pad |= ((1 << 31) | (1 << 30));
omap4_ctrl_pad_writel(mcbsp_pad, OMAP2_CONTROL_DEVCONF0);
In case when the kernel is booted with DT blob the pinctrl-single will be
provided as soon as it is enabled on the platform.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
arch/arm/mach-omap2/mcbsp.c | 77 ---
arch/arm/plat-omap/include/plat/mcbsp.h |1 -
sound/soc/omap/mcbsp.c | 31
sound/soc/omap/mcbsp.h |3 -
sound/soc/omap/omap-mcbsp.c | 32 +
sound/soc/omap/omap-mcbsp.h |4 --
6 files changed, 3 insertions(+), 145 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 6e046e1..660e00b 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -25,8 +25,6 @@
#include
#include
-#include "control.h"
-
/*
* FIXME: Find a mechanism to enable/disable runtime the McBSP ICLK autoidle.
* Sidetone needs non-gated ICLK and sidetone autoidle is broken.
@@ -34,73 +32,6 @@
#include "cm2xxx_3xxx.h"
#include "cm-regbits-34xx.h"
-/* McBSP1 internal signal muxing function for OMAP2/3 */
-static int omap2_mcbsp1_mux_rx_clk(struct device *dev, const char *signal,
- const char *src)
-{
- u32 v;
-
- v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
-
- if (!strcmp(signal, "clkr")) {
- if (!strcmp(src, "clkr"))
- v &= ~OMAP2_MCBSP1_CLKR_MASK;
- else if (!strcmp(src, "clkx"))
- v |= OMAP2_MCBSP1_CLKR_MASK;
- else
- return -EINVAL;
- } else if (!strcmp(signal, "fsr")) {
- if (!strcmp(src, "fsr"))
- v &= ~OMAP2_MCBSP1_FSR_MASK;
- else if (!strcmp(src, "fsx"))
- v |= OMAP2_MCBSP1_FSR_MASK;
- else
- return -EINVAL;
- } else {
- return -EINVAL;
- }
-
- omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
-
- return 0;
-}
-
-/* McBSP4 internal signal muxing function for OMAP4 */
-#define OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_FSX(1 << 31)
-#define OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_CLKX (1 << 30)
-static int omap4_mcbsp4_mux_rx_clk(struct device *dev, const char *signal,
- const char *src)
-{
- u32 v;
-
- /*
-* In CONTROL_MCBSPLP register only bit 30 (CLKR mux), and bit 31 (FSR
-* mux) is used */
- v = omap4_ctrl_pad_readl(OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_MCBSPLP);
-
- if (!strcmp(signal, "clkr")) {
- if (!strcmp(src, "clkr"))
- v &= ~OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_CLKX;
- else if (!strcmp(src, "clkx"))
- v |= OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_CLKX;
- else
- return -EINVAL;
- } else if (!strcmp(signal, "fsr")) {
- if (!strcmp(src, "fsr"))
- v &= ~OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_FSX;
- else if (!strcmp(src, "fsx"))
- v |= OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_FSX;
- else
- return -EINVAL;
- } else {
- return -EINVAL;
- }
-
- omap4_ctrl_pad_writel(v, OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_MCBSPLP);
-
- return 0;
-}
-
static int omap3_enable_st_clock(unsigned int id, bool enable)
{
unsigned int w;
@@ -143,14 +74,6 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh,
void *unused)
pdata->has_ccr = true;
}
- /* On OMAP2/3 the McBSP1 port has 6 pin configuration */
- if (id == 1 && oh->class->rev < MCBSP_CONFIG_TYPE4)
- pdata->mux_signal = omap2_mcbsp1_mux_rx_clk;
-
- /* On OMAP4 the McBSP4 port has 6 pin configuration */
- if (id == 4 && oh->class->rev == MCBSP_CONFIG_TYPE4)
- pdata->mux_signal = omap4_mcbsp4_mux_rx_clk;
-
if (oh->class->rev == MCBSP_CONFIG_TYPE2) {
/* The FIFO has 128 locations */
pdata->buffer_size = 0x80;
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/includ
[PATCH v3 4/9] ASoC: am3517evm: Do not configure McBSP1 CLKR/FSR signal muxing
The muxing is done at board level, no need to do it in the ASoC machine
driver.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
sound/soc/omap/am3517evm.c | 20 ++--
1 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/sound/soc/omap/am3517evm.c b/sound/soc/omap/am3517evm.c
index 009533a..a997988 100644
--- a/sound/soc/omap/am3517evm.c
+++ b/sound/soc/omap/am3517evm.c
@@ -47,26 +47,10 @@ static int am3517evm_hw_params(struct snd_pcm_substream
*substream,
/* Set the codec system clock for DAC and ADC */
ret = snd_soc_dai_set_sysclk(codec_dai, 0,
CODEC_CLOCK, SND_SOC_CLOCK_IN);
- if (ret < 0) {
+ if (ret < 0)
printk(KERN_ERR "can't set codec system clock\n");
- return ret;
- }
-
- ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0,
- SND_SOC_CLOCK_IN);
- if (ret < 0) {
- printk(KERN_ERR "can't set CPU system clock
OMAP_MCBSP_CLKR_SRC_CLKX\n");
- return ret;
- }
- snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0,
- SND_SOC_CLOCK_IN);
- if (ret < 0) {
- printk(KERN_ERR "can't set CPU system clock
OMAP_MCBSP_FSR_SRC_FSX\n");
- return ret;
- }
-
- return 0;
+ return ret;
}
static struct snd_soc_ops am3517evm_ops = {
--
1.7.8.6
--
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 v3 3/9] ARM: OMAP: board-am3517evm: Configure McBSP1 CLKR/FSR signal source
am3517evm board uses McBSP1 for audio with 4pin configuration.
The CLKR/FSR signals need to be connected to CLKX/FSX pin of the SoC in
this case.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
arch/arm/mach-omap2/board-am3517evm.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 18f6010..592812a 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -264,6 +264,16 @@ static __init void am3517_evm_musb_init(void)
usb_musb_init(&musb_board_data);
}
+static __init void am3517_evm_mcbsp1_init(void)
+{
+ u32 devconf0;
+
+ /* McBSP1 CLKR/FSR signal to be connected to CLKX/FSX pin */
+ devconf0 = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
+ devconf0 |= OMAP2_MCBSP1_CLKR_MASK | OMAP2_MCBSP1_FSR_MASK;
+ omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
+}
+
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
@@ -373,6 +383,9 @@ static void __init am3517_evm_init(void)
/* MUSB */
am3517_evm_musb_init();
+ /* McBSP1 */
+ am3517_evm_mcbsp1_init();
+
/* MMC init function */
omap_hsmmc_init(mmc);
}
--
1.7.8.6
--
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 v3 2/9] ARM: OMAP: mcbsp: Enable FIFO use for OMAP2430
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
arch/arm/mach-omap2/mcbsp.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index ebc801e..6e046e1 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -151,7 +151,10 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh,
void *unused)
if (id == 4 && oh->class->rev == MCBSP_CONFIG_TYPE4)
pdata->mux_signal = omap4_mcbsp4_mux_rx_clk;
- if (oh->class->rev == MCBSP_CONFIG_TYPE3) {
+ if (oh->class->rev == MCBSP_CONFIG_TYPE2) {
+ /* The FIFO has 128 locations */
+ pdata->buffer_size = 0x80;
+ } else if (oh->class->rev == MCBSP_CONFIG_TYPE3) {
if (id == 2)
/* The FIFO has 1024 + 256 locations */
pdata->buffer_size = 0x500;
--
1.7.8.6
--
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 v3 1/9] ARM/ASoC: omap-mcbsp: Move OMAP2+ clock parenting code to ASoC driver
Move the McBSP CLKS re-parenting code to ASoC driver from
arch/arm/mach-omap2.
The call fort the re-parenting has been already limited to OMAP2+ SoC in
the ASoC driver. There is no longer need to have callback function for it.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
arch/arm/mach-omap2/mcbsp.c | 40 ---
arch/arm/plat-omap/include/plat/mcbsp.h |1 -
sound/soc/omap/mcbsp.c | 31
3 files changed, 26 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 577cb77..ebc801e 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -101,45 +101,6 @@ static int omap4_mcbsp4_mux_rx_clk(struct device *dev,
const char *signal,
return 0;
}
-/* McBSP CLKS source switching function */
-static int omap2_mcbsp_set_clk_src(struct device *dev, struct clk *clk,
- const char *src)
-{
- struct clk *fck_src;
- char *fck_src_name;
- int r;
-
- if (!strcmp(src, "clks_ext"))
- fck_src_name = "pad_fck";
- else if (!strcmp(src, "clks_fclk"))
- fck_src_name = "prcm_fck";
- else
- return -EINVAL;
-
- fck_src = clk_get(dev, fck_src_name);
- if (IS_ERR_OR_NULL(fck_src)) {
- pr_err("omap-mcbsp: %s: could not clk_get() %s\n", "clks",
- fck_src_name);
- return -EINVAL;
- }
-
- pm_runtime_put_sync(dev);
-
- r = clk_set_parent(clk, fck_src);
- if (IS_ERR_VALUE(r)) {
- pr_err("omap-mcbsp: %s: could not clk_set_parent() to %s\n",
- "clks", fck_src_name);
- clk_put(fck_src);
- return -EINVAL;
- }
-
- pm_runtime_get_sync(dev);
-
- clk_put(fck_src);
-
- return 0;
-}
-
static int omap3_enable_st_clock(unsigned int id, bool enable)
{
unsigned int w;
@@ -181,7 +142,6 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh,
void *unused)
pdata->reg_size = 4;
pdata->has_ccr = true;
}
- pdata->set_clk_src = omap2_mcbsp_set_clk_src;
/* On OMAP2/3 the McBSP1 port has 6 pin configuration */
if (id == 1 && oh->class->rev < MCBSP_CONFIG_TYPE4)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 1881412..0a7d5ca 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -47,7 +47,6 @@ struct omap_mcbsp_platform_data {
bool has_wakeup; /* Wakeup capability */
bool has_ccr; /* Transceiver has configuration control registers */
int (*enable_st_clock)(unsigned int, bool);
- int (*set_clk_src)(struct device *dev, struct clk *clk, const char
*src);
int (*mux_signal)(struct device *dev, const char *signal, const char
*src);
};
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
index d33c48b..935ccf6 100644
--- a/sound/soc/omap/mcbsp.c
+++ b/sound/soc/omap/mcbsp.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
@@ -726,19 +727,39 @@ void omap_mcbsp_stop(struct omap_mcbsp *mcbsp, int tx,
int rx)
int omap2_mcbsp_set_clks_src(struct omap_mcbsp *mcbsp, u8 fck_src_id)
{
+ struct clk *fck_src;
const char *src;
+ int r;
if (fck_src_id == MCBSP_CLKS_PAD_SRC)
- src = "clks_ext";
+ src = "pad_fck";
else if (fck_src_id == MCBSP_CLKS_PRCM_SRC)
- src = "clks_fclk";
+ src = "prcm_fck";
else
return -EINVAL;
- if (mcbsp->pdata->set_clk_src)
- return mcbsp->pdata->set_clk_src(mcbsp->dev, mcbsp->fclk, src);
- else
+ fck_src = clk_get(mcbsp->dev, src);
+ if (IS_ERR(fck_src)) {
+ dev_err(mcbsp->dev, "CLKS: could not clk_get() %s\n", src);
return -EINVAL;
+ }
+
+ pm_runtime_put_sync(mcbsp->dev);
+
+ r = clk_set_parent(mcbsp->fclk, fck_src);
+ if (r) {
+ dev_err(mcbsp->dev, "CLKS: could not clk_set_parent() to %s\n",
+ src);
+ clk_put(fck_src);
+ return r;
+ }
+
+ pm_runtime_get_sync(mcbsp->dev);
+
+ clk_put(fck_src);
+
+ return 0;
+
}
int omap_mcbsp_6pin_src_mux(struct omap_mcbsp *mcbsp, u8 mux)
--
1.7.8.6
--
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 v3 0/9] ARM/ASoC: OMAP McBSP device tree support
Hello, Changes since v2: - Replaced the IS_ERR_OR_NULL() with IS_ERR() Changes since v1: - ICLK workaround for the sidetone module has been kept for legacy mode. Intro mail from v2: in order to be able to add DT support for the McBSP driver which is used on all OMAP platforms (OMAP1/2/3/4/5) I needed to make some cleanups to the stack: - Removing callbacks used by the driver for - clock re-parenting (code moved to sound driver) - FSR/CLKR mux configuration (from now on it need to be done at board level) This mux is board specific and depends on the wiring. - Replaced the cpu_is_omap* checks with future proof check. - The FIFO was not enabled on OMAP2430 SoC It has been tested on BeagleBoard (with legacy and DT boot). The series changes McBSP related files mostly. It would be great if the whole series could go via audio tree (if the patches are OK and it is fine by Tony). For DT booted kernel on OMAP3 proper ICLK woraround need to be implemented. At the moment I don't see this as a stopper since we can not properly boot OMAP3 devices (especially rx51 which is using the ST). Other OMAP revisions does not have ST block so the missing workaround is not going to hurt them. I'm working on a solution which can replace the current workaround with a generic implementation to support DT and non DT booted kernels. Regards, Peter --- Peter Ujfalusi (9): ARM/ASoC: omap-mcbsp: Move OMAP2+ clock parenting code to ASoC driver ARM: OMAP: mcbsp: Enable FIFO use for OMAP2430 ARM: OMAP: board-am3517evm: Configure McBSP1 CLKR/FSR signal source ASoC: am3517evm: Do not configure McBSP1 CLKR/FSR signal muxing ARM/ASoC: omap-mcbsp: Remove CLKR/FSR mux configuration code ASoC: omap-mcbsp: Remove unused defines ASoC: omap-mcbsp: Remove cpu_is_omap* checks from the code ARM: OMAP2+: McBSP: Do not create legacy devices when booting with DT data ASoC: omap-mcbsp: Add device tree bindings .../devicetree/bindings/sound/omap-mcbsp.txt | 45 +++ arch/arm/mach-omap2/board-am3517evm.c | 13 ++ arch/arm/mach-omap2/mcbsp.c| 126 +-- arch/arm/plat-omap/include/plat/mcbsp.h|2 - sound/soc/omap/am3517evm.c | 20 +--- sound/soc/omap/mcbsp.c | 54 - sound/soc/omap/mcbsp.h |3 - sound/soc/omap/omap-mcbsp.c| 106 +++- sound/soc/omap/omap-mcbsp.h| 20 --- 9 files changed, 162 insertions(+), 227 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/omap-mcbsp.txt -- 1.7.8.6 -- 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 3/4] arm/dts: Add tps65910 regulator DT data to am335x-evm.dts
Mark, Small correction On Thu, Aug 16, 2012 at 18:52:25, AnilKumar, Chimata wrote: > Mark, > > On Wed, Aug 15, 2012 at 22:24:32, Mark Brown wrote: > > On Wed, Aug 15, 2012 at 04:47:02PM +, AnilKumar, Chimata wrote: > > > On Wed, Aug 15, 2012 at 18:23:39, Mark Brown wrote: > > > > > > If you have all these unrelated supplies in the system then your device > > > > tree should accurately reflect that. However this would be a very > > > > > In that case I have to add all these fixed regulators. > > > > Why? You then immediately go on to say... > > Because all the nodes/regulators should be provided/registered otherwise > "regulator_dev_lookup" returns NULL if there are no regulator matches with > the supply_name. > > I have gone through this thread > http://patchwork.ozlabs.org/patch/166682/ > > But problem here is single input supply battery/main is not sufficient. > > pmic->desc[i].supply_name = info->vin_name; > with this assignment regulator core searches for exact supply name vcc1 or > vcc2 etc if there are no matches then it will not register any regulators. > > > > > > > unusual hardware design. Usually there would be a very small set of > > > > system supply rails, frequently only one. > > > > > In case of AM335X-EVM one dedicated supply (5v) feeding to all the input > > > supplies (vcc1-7 and vccio) of the regulators. > > > > ...that they all map onto the same physical supply? > > > > Yes single physical supply, if we want to add single fixed regulator node > to feed all the regulators then driver have to modify to support this. > Similar to revert of "regulator: tps65910: add support for input supply" ^^^ Copy/paste error Similar to revert of this patch "regulator: tps65910: set input_supply on desc unconditionally" Thanks AnilKumar -- 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 3/4] arm/dts: Add tps65910 regulator DT data to am335x-evm.dts
Mark, On Wed, Aug 15, 2012 at 22:24:32, Mark Brown wrote: > On Wed, Aug 15, 2012 at 04:47:02PM +, AnilKumar, Chimata wrote: > > On Wed, Aug 15, 2012 at 18:23:39, Mark Brown wrote: > > > > If you have all these unrelated supplies in the system then your device > > > tree should accurately reflect that. However this would be a very > > > In that case I have to add all these fixed regulators. > > Why? You then immediately go on to say... Because all the nodes/regulators should be provided/registered otherwise "regulator_dev_lookup" returns NULL if there are no regulator matches with the supply_name. I have gone through this thread http://patchwork.ozlabs.org/patch/166682/ But problem here is single input supply battery/main is not sufficient. pmic->desc[i].supply_name = info->vin_name; with this assignment regulator core searches for exact supply name vcc1 or vcc2 etc if there are no matches then it will not register any regulators. > > > > unusual hardware design. Usually there would be a very small set of > > > system supply rails, frequently only one. > > > In case of AM335X-EVM one dedicated supply (5v) feeding to all the input > > supplies (vcc1-7 and vccio) of the regulators. > > ...that they all map onto the same physical supply? > Yes single physical supply, if we want to add single fixed regulator node to feed all the regulators then driver have to modify to support this. Similar to revert of "regulator: tps65910: add support for input supply" Patch. Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Expose the OMAP Z-Order property through DRM
On Thu, Aug 16, 2012 at 8:00 AM, Ville Syrjälä
wrote:
> On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
>> From: Andre Renaud
>>
>> Added support for zorder changes through DRM plane properties
>>
>> Signed-off-by: Andre Renaud
>> Signed-off-by: Rob Clark
>> ---
>> drivers/staging/omapdrm/omap_drv.h |1 +
>> drivers/staging/omapdrm/omap_plane.c | 19 +++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/staging/omapdrm/omap_drv.h
>> b/drivers/staging/omapdrm/omap_drv.h
>> index b103d28..9dc72d1 100644
>> --- a/drivers/staging/omapdrm/omap_drv.h
>> +++ b/drivers/staging/omapdrm/omap_drv.h
>> @@ -62,6 +62,7 @@ struct omap_drm_private {
>>
>> /* properties: */
>> struct drm_property *rotation_prop;
>> + struct drm_property *zorder_prop;
>> };
>>
>> /* this should probably be in drm-core to standardize amongst drivers */
>> diff --git a/drivers/staging/omapdrm/omap_plane.c
>> b/drivers/staging/omapdrm/omap_plane.c
>> index 6931d06..4bde639 100644
>> --- a/drivers/staging/omapdrm/omap_plane.c
>> +++ b/drivers/staging/omapdrm/omap_plane.c
>> @@ -433,6 +433,15 @@ void omap_plane_install_properties(struct drm_plane
>> *plane,
>> priv->rotation_prop = prop;
>> }
>> drm_object_attach_property(obj, prop, 0);
>> +
>> +prop = priv->zorder_prop;
>> +if (!prop) {
>> + prop = drm_property_create_range(dev, 0, "zorder", 0, 3);
>> + if (prop == NULL)
>> + return;
>> + priv->zorder_prop = prop;
>> + }
>> + drm_object_attach_property(obj, prop, 0);
>> }
>>
>> int omap_plane_set_property(struct drm_plane *plane,
>> @@ -452,6 +461,16 @@ int omap_plane_set_property(struct drm_plane *plane,
>> ret = omap_plane_dpms(plane, DRM_MODE_DPMS_ON);
>> else
>> ret = 0;
>> + } else if (property == priv->zorder_prop) {
>> + struct omap_overlay *ovl = omap_plane->ovl;
>> +
>> + DBG("%s: zorder: %d", ovl->name, (uint32_t)val);
>> + omap_plane->info.zorder = val;
>
> What would happen when there's a conflicting assignment between two
> planes?
non-good things.. basically as part of re-working the
omapdss<->omapdrm stuff, I'll have a good point in omapdrm before
setting GO bit(s) where I can calculate the actual z-order from that
is set from userspace. If two planes had same z-order from userspace,
omapdrm would simply put one in front of the other. If the planes
aren't overlapping, this is fine.
> I tried to think of a decent way to do this stuff, but some hardware
> can have rather complicated stacking order limitations. One idea I
> came up with was to have an enum prop on the crtc, where the individual
> enum value names would somehow describe the whole stacking order within
> the crtc. That way user space couldn't even try to use an unsupported
> configuration. The downside is that user space would need to parse
> those strings if it wants to do some automagic stacking order changes,
> which means the string format would need some though.
I was thinking about this, but then you run into the same issue if you
move a plane from one CRTC to another without userspace setting the
property again. In the end if userspace is ambiguous the driver has
to just arbitrarily pick some z-order to keep the hw happy.
BR,
-R
> --
> Ville Syrjälä
> Intel OTC
> --
> 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: [PATCH 6/6] OMAPDSS: VENC: Maintian copy of video output polarity in private data
On Thu, 2012-08-16 at 17:57 +0530, Archit Taneja wrote:
> On Thursday 16 August 2012 05:08 PM, Tomi Valkeinen wrote:
> > On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
> >> The VENC driver currently relies on the omap_dss_device struct to
> >> configure the
> >> video output polarity. This makes the VENC interface driver dependent on
> >> the
> >> omap_dss_device struct.
> >>
> >> Make the VENC driver data maintain it's own polarity field. A panel driver
> >> is expected to call omapdss_venc_set_vid_out_polarity() before enabling the
> >> interface.
> >>
> >> Signed-off-by: Archit Taneja
> >> ---
> >> drivers/video/omap2/dss/dss.h|2 ++
> >> drivers/video/omap2/dss/venc.c | 13 -
> >> drivers/video/omap2/dss/venc_panel.c |6 ++
> >> 3 files changed, 20 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> >> index c17d298..b2cf5530 100644
> >> --- a/drivers/video/omap2/dss/dss.h
> >> +++ b/drivers/video/omap2/dss/dss.h
> >> @@ -479,6 +479,8 @@ u32 omapdss_venc_get_wss(struct omap_dss_device
> >> *dssdev);
> >> int omapdss_venc_set_wss(struct omap_dss_device *dssdev, u32 wss);
> >> void omapdss_venc_set_type(struct omap_dss_device *dssdev,
> >>enum omap_dss_venc_type type);
> >> +void omapdss_venc_set_vid_out_polarity(struct omap_dss_device *dssdev,
> >> + enum omap_dss_signal_level vid_out_pol);
> >> int venc_panel_init(void);
> >> void venc_panel_exit(void);
> >>
> >> diff --git a/drivers/video/omap2/dss/venc.c
> >> b/drivers/video/omap2/dss/venc.c
> >> index 2d90fcf..8cb372f 100644
> >> --- a/drivers/video/omap2/dss/venc.c
> >> +++ b/drivers/video/omap2/dss/venc.c
> >> @@ -303,6 +303,7 @@ static struct {
> >>
> >>struct omap_video_timings timings;
> >>enum omap_dss_venc_type type;
> >> + enum omap_dss_signal_level vid_out_pol;
> >> } venc;
> >>
> >> static inline void venc_write_reg(int idx, u32 val)
> >> @@ -447,7 +448,7 @@ static int venc_power_on(struct omap_dss_device
> >> *dssdev)
> >>else /* S-Video */
> >>l |= (1 << 0) | (1 << 2);
> >>
> >> - if (dssdev->phy.venc.invert_polarity == false)
> >> + if (venc.vid_out_pol == OMAPDSS_SIG_ACTIVE_HIGH)
> >>l |= 1 << 3;
> >
> > Are you sure this is correct? I know practically nothing about analog
> > TV, but the TRM doesn't seem to say much about that bit, except it can
> > be used to "invert the video output". It doesn't say there's an
> > active/inactive level for the signal.
>
> Well, the code works :), I'm also not totally sure about whether it
You could put there APPLE and ORANGE enum values, and it'd still work =)
> should be represented as a 2-level signal, it seemed like it would be
> nicer to give it a signal level rather than keeping it as a bool, which
> could vary for other SoC's?
It may be really a bool. TRM says "This may be used to
correct for inversion in an external video amplifier". I don't think
there are any digital on/off signals in analog video output, so I'm
guessing it's really inverting (some parts of) the analog signal. If so,
a boolean invert field sounds correct to me.
Actually, check this out:
http://books.google.fi/books?id=P6BlcWaizHUC&pg=PT81&lpg=PT81&dq=composite+video+polarity&source=bl&ots=-gsl0Exv5R&sig=gMylEnoV9ozRwM4RX2iQFqhRpP8&hl=en&sa=X&ei=0u8sUIe3KYXh4QTf9YDQBA&redir_esc=y#v=onepage&q=composite%20video%20polarity&f=false
A monster url, here's a tinyurl version: http://tinyurl.com/clceb6t
2.16 section there shows signal polarities. I'm not sure if it's the
same one that we're discussing, but sounds like it.
I don't think ACTIVE_LOW/HIGH fits into that kind of polarity. Perhaps a
bool is not quite right for it either, as I'm not sure there's a
"normal" polarity. But I'd go forward with out current bool, and fix it
when somebody who understands this stuff tells us what to do =).
> I am considering not to pass this via the panel driver for now, I don't
> know if all VENC IPs needs to do this, maybe it's okay to leave this
> dssdev reference for now?
I don't know if other VENC IPs support this or not, but the TRM refers
to external amplifier, so it sounds like a thing that would exist on
other IPs also.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 2/2] Expose the OMAP Z-Order property through DRM
On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
> From: Andre Renaud
>
> Added support for zorder changes through DRM plane properties
>
> Signed-off-by: Andre Renaud
> Signed-off-by: Rob Clark
> ---
> drivers/staging/omapdrm/omap_drv.h |1 +
> drivers/staging/omapdrm/omap_plane.c | 19 +++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/staging/omapdrm/omap_drv.h
> b/drivers/staging/omapdrm/omap_drv.h
> index b103d28..9dc72d1 100644
> --- a/drivers/staging/omapdrm/omap_drv.h
> +++ b/drivers/staging/omapdrm/omap_drv.h
> @@ -62,6 +62,7 @@ struct omap_drm_private {
>
> /* properties: */
> struct drm_property *rotation_prop;
> + struct drm_property *zorder_prop;
> };
>
> /* this should probably be in drm-core to standardize amongst drivers */
> diff --git a/drivers/staging/omapdrm/omap_plane.c
> b/drivers/staging/omapdrm/omap_plane.c
> index 6931d06..4bde639 100644
> --- a/drivers/staging/omapdrm/omap_plane.c
> +++ b/drivers/staging/omapdrm/omap_plane.c
> @@ -433,6 +433,15 @@ void omap_plane_install_properties(struct drm_plane
> *plane,
> priv->rotation_prop = prop;
> }
> drm_object_attach_property(obj, prop, 0);
> +
> +prop = priv->zorder_prop;
> +if (!prop) {
> + prop = drm_property_create_range(dev, 0, "zorder", 0, 3);
> + if (prop == NULL)
> + return;
> + priv->zorder_prop = prop;
> + }
> + drm_object_attach_property(obj, prop, 0);
> }
>
> int omap_plane_set_property(struct drm_plane *plane,
> @@ -452,6 +461,16 @@ int omap_plane_set_property(struct drm_plane *plane,
> ret = omap_plane_dpms(plane, DRM_MODE_DPMS_ON);
> else
> ret = 0;
> + } else if (property == priv->zorder_prop) {
> + struct omap_overlay *ovl = omap_plane->ovl;
> +
> + DBG("%s: zorder: %d", ovl->name, (uint32_t)val);
> + omap_plane->info.zorder = val;
What would happen when there's a conflicting assignment between two
planes?
I tried to think of a decent way to do this stuff, but some hardware
can have rather complicated stacking order limitations. One idea I
came up with was to have an enum prop on the crtc, where the individual
enum value names would somehow describe the whole stacking order within
the crtc. That way user space couldn't even try to use an unsupported
configuration. The downside is that user space would need to parse
those strings if it wants to do some automagic stacking order changes,
which means the string format would need some though.
--
Ville Syrjälä
Intel OTC
--
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 6/6] OMAPDSS: VENC: Maintian copy of video output polarity in private data
On Thursday 16 August 2012 05:08 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
The VENC driver currently relies on the omap_dss_device struct to configure the
video output polarity. This makes the VENC interface driver dependent on the
omap_dss_device struct.
Make the VENC driver data maintain it's own polarity field. A panel driver
is expected to call omapdss_venc_set_vid_out_polarity() before enabling the
interface.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dss.h|2 ++
drivers/video/omap2/dss/venc.c | 13 -
drivers/video/omap2/dss/venc_panel.c |6 ++
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index c17d298..b2cf5530 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -479,6 +479,8 @@ u32 omapdss_venc_get_wss(struct omap_dss_device *dssdev);
int omapdss_venc_set_wss(struct omap_dss_device *dssdev, u32 wss);
void omapdss_venc_set_type(struct omap_dss_device *dssdev,
enum omap_dss_venc_type type);
+void omapdss_venc_set_vid_out_polarity(struct omap_dss_device *dssdev,
+ enum omap_dss_signal_level vid_out_pol);
int venc_panel_init(void);
void venc_panel_exit(void);
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 2d90fcf..8cb372f 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -303,6 +303,7 @@ static struct {
struct omap_video_timings timings;
enum omap_dss_venc_type type;
+ enum omap_dss_signal_level vid_out_pol;
} venc;
static inline void venc_write_reg(int idx, u32 val)
@@ -447,7 +448,7 @@ static int venc_power_on(struct omap_dss_device *dssdev)
else /* S-Video */
l |= (1 << 0) | (1 << 2);
- if (dssdev->phy.venc.invert_polarity == false)
+ if (venc.vid_out_pol == OMAPDSS_SIG_ACTIVE_HIGH)
l |= 1 << 3;
Are you sure this is correct? I know practically nothing about analog
TV, but the TRM doesn't seem to say much about that bit, except it can
be used to "invert the video output". It doesn't say there's an
active/inactive level for the signal.
Well, the code works :), I'm also not totally sure about whether it
should be represented as a 2-level signal, it seemed like it would be
nicer to give it a signal level rather than keeping it as a bool, which
could vary for other SoC's?
I am considering not to pass this via the panel driver for now, I don't
know if all VENC IPs needs to do this, maybe it's okay to leave this
dssdev reference for now?
Archit
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 1/6] OMAPDSS: DSI: Maintain copy of operation mode in driver data
On Thu, 2012-08-16 at 17:41 +0530, Archit Taneja wrote: > On Thursday 16 August 2012 04:49 PM, Tomi Valkeinen wrote: > > On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote: > >> The DSI driver currently relies on the omap_dss_device struct to know the > >> mode > >> of operation of the DSI protocol(command or video mode). This makes the DSI > >> interface driver dependent on the omap_dss_device struct. > >> > >> Make the DSI driver data maintain it's own operation mode field. The panel > >> driver is expected to call omapdss_dsi_set_operation_mode() before the > >> interface > >> is enabled. > >> > >> Signed-off-by: Archit Taneja > >> --- > >> drivers/video/omap2/displays/panel-taal.c |1 + > >> drivers/video/omap2/dss/dsi.c | 42 > >> + > >> include/video/omapdss.h |2 ++ > >> 3 files changed, 34 insertions(+), 11 deletions(-) > >> > >> diff --git a/drivers/video/omap2/displays/panel-taal.c > >> b/drivers/video/omap2/displays/panel-taal.c > >> index d220f19..649247f 100644 > >> --- a/drivers/video/omap2/displays/panel-taal.c > >> +++ b/drivers/video/omap2/displays/panel-taal.c > >> @@ -1063,6 +1063,7 @@ static int taal_power_on(struct omap_dss_device > >> *dssdev) > >>omapdss_dsi_set_size(dssdev, dssdev->panel.timings.x_res, > >>dssdev->panel.timings.y_res); > >>omapdss_dsi_set_pixel_format(dssdev, dssdev->panel.dsi_pix_fmt); > >> + omapdss_dsi_set_operation_mode(dssdev, dssdev->panel.dsi_mode); > > > > Taal is always in cmd mode. Shouldn't we just use a hardcoded value > > here? > > > > Actually I think the same goes for the pix_fmt above. It's always the > > same for Taal. > > Yes, I'll do this. I guess we could gradually remove some of these > fields from omap_dss_device? Can't we? I mean, if there are no panels > which can ever support command and video mode together, then we can just > leave it to the driver to hold this information. Yes, we can remove them. Even if there was a panel taht supports both cmd and video mode, it would be the panel driver's job to handle it, and any parameters passed to the driver would happen via the panel's own platform data, not via dssdev. Tomi signature.asc Description: This is a digitally signed message part
[PATCH v4 1/4] arm/dts: AM33XX: Add basic pinctrl device tree data
Adds basic pinctrl device tree data for AM33XX family of devices.
This patch is based on the pinctrl-single driver.
Signed-off-by: AnilKumar Ch
---
Changes from v3:
- Updated the reg length based on latest AM335x TRM.
Changes from v2:
- user led pinmux comments updated according to Tony's
comment.
Changes from v1:
- Rebased the patches based on latest pinctrl-single driver
arch/arm/boot/dts/am33xx.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index dde76f7..dfe9c559 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux@44E10800 {
+ compatible = "pinctrl-single";
+ reg = <0x44E10800 0x0238>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x7F>;
+ };
+
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex.Since
--
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 v4 2/4] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
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 a7906cb..58f5042 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,6 +18,20 @@
reg = <0x8000 0x1000>; /* 256 MB */
};
+ am3358_pinmux: pinmux@44E10800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&userled_pins>;
+
+ userled_pins: pinmux_userled_pins {
+ 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 v3 4/4] arm/dts: AM33XX: Add D_CAN device tree data
Add Bosch D_CAN controller device tree data to AM33XX dtsi
file by adding d_can device nodes with all the necessary
parameters.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evm.dts |4
arch/arm/boot/dts/am33xx.dtsi| 18 ++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index a64c30a..1e1fc15 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -34,5 +34,9 @@
uart1: serial@44E09000 {
status = "okay";
};
+
+ dcan1: d_can@481D {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index dfe9c559..d965137 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -177,5 +177,23 @@
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
};
+
+ dcan0: d_can@481CC000 {
+ compatible = "bosch,d_can";
+ ti,hwmods = "d_can0";
+ reg = <0x481CC000 0x2000>;
+ interrupts = <52>;
+ interrupt-parent = <&intc>;
+ status = "disabled";
+ };
+
+ dcan1: d_can@481D {
+ compatible = "bosch,d_can";
+ ti,hwmods = "d_can1";
+ reg = <0x481D 0x2000>;
+ interrupts = <55>;
+ interrupt-parent = <&intc>;
+ status = "disabled";
+ };
};
};
--
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 v3 3/4] arm/dts: AM33XX: Configure pinmuxs for D_CAN1 on AM335x-EVM
Add D_CAN1 pinctrl node to am3358_pinmux master node to export
D_CAN functionality on AM335x EVM according to pinctrl-single
driver.
Signed-off-by: AnilKumar Ch
---
Changes from v2:
- Incorporated Vaibhav H's comments on v2
* Added dcan0 instances to am33xx.dtsi file
Changes from v1:
- These two patches separated from c_can DT support
patch series.
arch/arm/boot/dts/am335x-evm.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 5dd8a6b..a64c30a 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -18,6 +18,18 @@
reg = <0x8000 0x1000>; /* 256 MB */
};
+ am3358_pinmux: pinmux@44E10800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&d_can1_pins>;
+
+ d_can1_pins: pinmux_d_can_pins {
+ pinctrl-single,pins = <
+ 0x168 0x2 /* uart0_ctsn.d_can1_tx, OUTPUT
| MODE2 */
+ 0x16C 0x32 /* uart0_rtsn.d_can1_rx,
INPUT_PULLUP | MODE2 */
+ >;
+ };
+ };
+
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 0/4] Add device tree data for AM33XX devices
Add pinctrl and d_can device tree data to AM33XX family of devices. First two patches add support for pinctrl DT data and rest adds dcan DT data. Reason behind combining these patches is to apply cleanly on linux-omap devel-dt tree because these are sequential patches. These patches were tested on AM335x-Bone and AM335x-EVM apply on linux-omap:devel-dt tree with this patch http://lkml.org/lkml/2012/8/15/106 AnilKumar Ch (4): arm/dts: AM33XX: Add basic pinctrl device tree data arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone arm/dts: AM33XX: Configure pinmuxs for D_CAN1 on AM335x-EVM arm/dts: AM33XX: Add D_CAN device tree data arch/arm/boot/dts/am335x-bone.dts | 14 ++ arch/arm/boot/dts/am335x-evm.dts | 16 arch/arm/boot/dts/am33xx.dtsi | 27 +++ 3 files changed, 57 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
Re: [PATCH 3/6] OMAPDSS: DSI: Maintain copy of video mode timings in driver data
On Thu, 2012-08-16 at 17:27 +0530, Archit Taneja wrote: > On Thursday 16 August 2012 05:01 PM, Tomi Valkeinen wrote: > > On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote: > >> The DSI driver currently relies on the omap_dss_device struct to receive > >> the > >> video mode timings requested by the panel driver. This makes the DSI > >> interface > >> driver dependent on the omap_dss_device struct. > >> > >> Make the DSI driver data maintain it's own video mode timings field. The > >> panel > >> driver is expected to call omapdss_dsi_set_videomode_timings() to > >> configure the > >> video mode timings before the interface is enabled. The function takes in a > >> void pointer rather than a pointer to omap_dss_dsi_videomode_timings > >> struct. > >> This is because this function will finally be an output op shared across > >> different outputs to set custom or private timings. > > > > I don't think the function should take a void * in any case. If we want > > to share the function, it should take a struct that perhaps contains an > > union of rfbi and dsi timings. > > > > But I'm not sure if there's any benefit for that... > > > > So do you see us having just one set_timings, which would take either > > the normal video timings, rfbi timings or dsi timings? > > I thought of having 2 timing ops, one is a standard "modeline like" > set_timings(), and the other a vague-ish set_custom_timings(). For > us(OMAP), we need to use it for DSI videomode and RFBI, we may reduce > that to only RFBI later if we calculate for DSI timings automatically. > > For these extra timings to be consistent across SoCs, we would need to > align to get a common struct of some sort, which could then have unions > as you said. For now, I thought having a void pointer might suffice. I would only use void * when it's a must, i.e. when really anything can be passed as a parameter. In our case, I think having just two separate functions is best. I think the timings in videomode and rfbi structs should be SoC independent even now, at least more or less. But you're right, it should be verified. And any names in the structs should be according to DBI or DSI spec, not OMAP. But this is for later. Tomi signature.asc Description: This is a digitally signed message part
[PATCH v2 3/3] gpio: Add basic support for TWL6040 GPOs
TWL6040 provides GPO lines to be used for controlling external devices.The
number
of lines different between versions: twl6040 have 3 GPO while TWL6041 have 1.
Signed-off-by: Sergio Aguirre
Signed-off-by: Peter Ujfalusi
Acked-by: Linus Walleij
---
drivers/gpio/Kconfig|7 ++
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-twl6040.c | 137 +++
3 files changed, 145 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/gpio-twl6040.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b16c8a7..f74633e 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -402,6 +402,13 @@ config GPIO_TWL4030
Say yes here to access the GPIO signals of various multi-function
power management chips from Texas Instruments.
+config GPIO_TWL6040
+ tristate "TWL6040 GPO"
+ depends on TWL6040_CORE
+ help
+ Say yes here to access the GPO signals of twl6040
+ audio chip from Texas Instruments.
+
config GPIO_WM831X
tristate "WM831x GPIOs"
depends on MFD_WM831X
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 153cace..f857b46 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_GPIO_TPS6586X) += gpio-tps6586x.o
obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
+obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
obj-$(CONFIG_GPIO_UCB1400) += gpio-ucb1400.o
obj-$(CONFIG_GPIO_VR41XX) += gpio-vr41xx.o
obj-$(CONFIG_GPIO_VX855) += gpio-vx855.o
diff --git a/drivers/gpio/gpio-twl6040.c b/drivers/gpio/gpio-twl6040.c
new file mode 100644
index 000..dd58e8b
--- /dev/null
+++ b/drivers/gpio/gpio-twl6040.c
@@ -0,0 +1,137 @@
+/*
+ * Access to GPOs on TWL6040 chip
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Authors:
+ * Sergio Aguirre
+ * Peter Ujfalusi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static struct gpio_chip twl6040gpo_chip;
+
+static int twl6040gpo_get(struct gpio_chip *chip, unsigned offset)
+{
+ struct twl6040 *twl6040 = dev_get_drvdata(chip->dev->parent);
+ int ret = 0;
+
+ ret = twl6040_reg_read(twl6040, TWL6040_REG_GPOCTL);
+ if (ret < 0)
+ return ret;
+
+ return (ret >> offset) & 1;
+}
+
+static int twl6040gpo_direction_out(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+ /* This only drives GPOs, and can't change direction */
+ return 0;
+}
+
+static void twl6040gpo_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+ struct twl6040 *twl6040 = dev_get_drvdata(chip->dev->parent);
+ int ret;
+ u8 gpoctl;
+
+ ret = twl6040_reg_read(twl6040, TWL6040_REG_GPOCTL);
+ if (ret < 0)
+ return;
+
+ if (value)
+ gpoctl = ret | (1 << offset);
+ else
+ gpoctl = ret & ~(1 << offset);
+
+ twl6040_reg_write(twl6040, TWL6040_REG_GPOCTL, gpoctl);
+}
+
+static struct gpio_chip twl6040gpo_chip = {
+ .label = "twl6040",
+ .owner = THIS_MODULE,
+ .get= twl6040gpo_get,
+ .direction_output = twl6040gpo_direction_out,
+ .set= twl6040gpo_set,
+ .can_sleep = 1,
+};
+
+/*--*/
+
+static int __devinit gpo_twl6040_probe(struct platform_device *pdev)
+{
+ struct twl6040_gpo_data *pdata = pdev->dev.platform_data;
+ struct device *twl6040_core_dev = pdev->dev.parent;
+ struct twl6040 *twl6040 = dev_get_drvdata(twl6040_core_dev);
+ int ret;
+
+ if (pdata)
+ twl6040gpo_chip.base = pdata->gpio_base;
+ else
+ twl6040gpo_chip.base = -1;
+
+ if (twl6040_get_revid(twl6040) < TWL6041_REV_ES2_0)
+ twl6040gpo_chip.ngpio = 3; /* twl6040 have 3 GPO */
+ else
+ twl6040gpo_chip.ngpio = 1; /* twl6041 have 1 GPO */
+
+ twl6040gpo_chip.dev = &pdev->de
[PATCH v2 2/3] mfd: twl6040: Add twl6040-gpio child
Add needed platform data structure and code to be able to load
the GPO child of twl6040.
Update the devicetree binding documentation at the same time.
Signed-off-by: Sergio Aguirre
Signed-off-by: Peter Ujfalusi
---
Documentation/devicetree/bindings/mfd/twl6040.txt |9 ++---
drivers/mfd/twl6040-core.c| 15 +++
include/linux/mfd/twl6040.h |9 -
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt
b/Documentation/devicetree/bindings/mfd/twl6040.txt
index c855240..0f5dd70 100644
--- a/Documentation/devicetree/bindings/mfd/twl6040.txt
+++ b/Documentation/devicetree/bindings/mfd/twl6040.txt
@@ -1,7 +1,7 @@
Texas Instruments TWL6040 family
-The TWL6040s are 8-channel high quality low-power audio codecs providing audio
-and vibra functionality on OMAP4+ platforms.
+The TWL6040s are 8-channel high quality low-power audio codecs providing audio,
+vibra and GPO functionality on OMAP4+ platforms.
They are connected ot the host processor via i2c for commands, McPDM for audio
data and commands.
@@ -10,6 +10,8 @@ Required properties:
- reg: must be 0x4b for i2c address
- interrupts: twl6040 has one interrupt line connecteded to the main SoC
- interrupt-parent: The parent interrupt controller
+- gpio-controller:
+- #gpio-cells = <1>: twl6040 provides GPO lines.
- twl6040,audpwron-gpio: Power on GPIO line for the twl6040
- vio-supply: Regulator for the twl6040 VIO supply
@@ -37,7 +39,6 @@ Example:
&i2c1 {
twl6040: twl@4b {
compatible = "ti,twl6040";
- reg = <0x4b>;
interrupts = <0 119 4>;
interrupt-parent = <&gic>;
@@ -60,3 +61,5 @@ Example:
};
};
};
+
+/include/ "twl6040.dtsi"
diff --git a/drivers/mfd/twl6040-core.c b/drivers/mfd/twl6040-core.c
index b0fad0f..413df8e 100644
--- a/drivers/mfd/twl6040-core.c
+++ b/drivers/mfd/twl6040-core.c
@@ -631,6 +631,21 @@ static int __devinit twl6040_probe(struct i2c_client
*client,
children++;
}
+ /*
+* Enable the GPO driver in the following cases:
+* DT booted kernel or legacy boot with valid gpo platform_data
+*/
+ if (!pdata || (pdata && pdata->gpo)) {
+ cell = &twl6040->cells[children];
+ cell->name = "twl6040-gpo";
+
+ if (pdata) {
+ cell->platform_data = pdata->gpo;
+ cell->pdata_size = sizeof(*pdata->gpo);
+ }
+ children++;
+ }
+
ret = mfd_add_devices(&client->dev, -1, twl6040->cells, children,
NULL, 0);
if (ret)
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
index 269b706..8991532 100644
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -158,7 +158,7 @@
#define TWL6040_VIBROCDET 0x20
#define TWL6040_TSHUTDET0x40
-#define TWL6040_CELLS 2
+#define TWL6040_CELLS 3
#define TWL6040_REV_ES1_0 0x00
#define TWL6040_REV_ES1_1 0x01 /* Rev ES1.1 and ES1.2 */
@@ -176,6 +176,8 @@
#define TWL6040_SYSCLK_SEL_LPPLL 0
#define TWL6040_SYSCLK_SEL_HPPLL 1
+#define TWL6040_GPO_MAX3
+
struct twl6040_codec_data {
u16 hs_left_step;
u16 hs_right_step;
@@ -192,12 +194,17 @@ struct twl6040_vibra_data {
int vddvibr_uV; /* VDDVIBR volt, set 0 for fixed reg */
};
+struct twl6040_gpo_data {
+ int gpio_base;
+};
+
struct twl6040_platform_data {
int audpwron_gpio; /* audio power-on gpio */
unsigned int irq_base;
struct twl6040_codec_data *codec;
struct twl6040_vibra_data *vibra;
+ struct twl6040_gpo_data *gpo;
};
struct regmap;
--
1.7.8.6
--
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 1/3] mfd: twl6040: Fix GPO mask
Signed-off-by: Peter Ujfalusi --- include/linux/mfd/twl6040.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h index eaad49f..269b706 100644 --- a/include/linux/mfd/twl6040.h +++ b/include/linux/mfd/twl6040.h @@ -143,7 +143,7 @@ #define TWL6040_GPO1 0x01 #define TWL6040_GPO2 0x02 -#define TWL6040_GPO3 0x03 +#define TWL6040_GPO3 0x04 /* ACCCTL (0x2D) fields */ -- 1.7.8.6 -- 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 0/3] MFD/GPIO: Add twl6040 GPO driver
Hello, Changes since v1: - Removed the ti,use-gpo property from DT bindings - Register the GPO driver if we booted with DT blob or in legacy if the pdata for the GPO driver is present - DT binding Documentation update The Documentation update has reference to the twl6040.dtsi file which will be created to hold the common/static properties for the twl6040. To avoid cross tree merge issues later I have only included the Documentation update to this series and I will send the actual .dtsi/.dts changes via linux-omap. If this is not a problem. The dependencies for this series are in mainline and I think this series can go via GPIO if Samuel agrees with the changes. Intro mail from v1: The following series adds support for the GPO (General Purpose Output) on the twl6040/41 audio chip. The series has been tested on SDP4430, compile tested for x86_64 and x86_32 bit to be sure it does not introduce build breakage. Regards, Peter --- Peter Ujfalusi (3): mfd: twl6040: Fix GPO mask mfd: twl6040: Add twl6040-gpio child gpio: Add basic support for TWL6040 GPOs Documentation/devicetree/bindings/mfd/twl6040.txt |9 +- drivers/gpio/Kconfig |7 + drivers/gpio/Makefile |1 + drivers/gpio/gpio-twl6040.c | 137 + drivers/mfd/twl6040-core.c| 15 +++ include/linux/mfd/twl6040.h | 11 ++- 6 files changed, 175 insertions(+), 5 deletions(-) create mode 100644 drivers/gpio/gpio-twl6040.c -- 1.7.8.6 -- 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 1/6] OMAPDSS: DSI: Maintain copy of operation mode in driver data
On Thursday 16 August 2012 04:49 PM, Tomi Valkeinen wrote: On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote: The DSI driver currently relies on the omap_dss_device struct to know the mode of operation of the DSI protocol(command or video mode). This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own operation mode field. The panel driver is expected to call omapdss_dsi_set_operation_mode() before the interface is enabled. Signed-off-by: Archit Taneja --- drivers/video/omap2/displays/panel-taal.c |1 + drivers/video/omap2/dss/dsi.c | 42 + include/video/omapdss.h |2 ++ 3 files changed, 34 insertions(+), 11 deletions(-) diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c index d220f19..649247f 100644 --- a/drivers/video/omap2/displays/panel-taal.c +++ b/drivers/video/omap2/displays/panel-taal.c @@ -1063,6 +1063,7 @@ static int taal_power_on(struct omap_dss_device *dssdev) omapdss_dsi_set_size(dssdev, dssdev->panel.timings.x_res, dssdev->panel.timings.y_res); omapdss_dsi_set_pixel_format(dssdev, dssdev->panel.dsi_pix_fmt); + omapdss_dsi_set_operation_mode(dssdev, dssdev->panel.dsi_mode); Taal is always in cmd mode. Shouldn't we just use a hardcoded value here? Actually I think the same goes for the pix_fmt above. It's always the same for Taal. Yes, I'll do this. I guess we could gradually remove some of these fields from omap_dss_device? Can't we? I mean, if there are no panels which can ever support command and video mode together, then we can just leave it to the driver to hold this information. Archit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] OMAPDSS: DSI: Maintain copy of video mode timings in driver data
On Thursday 16 August 2012 05:01 PM, Tomi Valkeinen wrote: On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote: The DSI driver currently relies on the omap_dss_device struct to receive the video mode timings requested by the panel driver. This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own video mode timings field. The panel driver is expected to call omapdss_dsi_set_videomode_timings() to configure the video mode timings before the interface is enabled. The function takes in a void pointer rather than a pointer to omap_dss_dsi_videomode_timings struct. This is because this function will finally be an output op shared across different outputs to set custom or private timings. I don't think the function should take a void * in any case. If we want to share the function, it should take a struct that perhaps contains an union of rfbi and dsi timings. But I'm not sure if there's any benefit for that... So do you see us having just one set_timings, which would take either the normal video timings, rfbi timings or dsi timings? I thought of having 2 timing ops, one is a standard "modeline like" set_timings(), and the other a vague-ish set_custom_timings(). For us(OMAP), we need to use it for DSI videomode and RFBI, we may reduce that to only RFBI later if we calculate for DSI timings automatically. For these extra timings to be consistent across SoCs, we would need to align to get a common struct of some sort, which could then have unions as you said. For now, I thought having a void pointer might suffice. Archit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver
Hi, > > It was an requirement back then that this driver needs to be a module as > > 99% of the N900 owners still don't even know they have this kind of > > capability on their devices, so it doesn't make sense to keep the module > > loaded unless the user actually needs it. > > I don't think that's so important --- currently the vast majority of the > N900 users using the mainline kernel compile it themselves. It's more > important to have a clean implementation at this point. I would like to enable this feature for the Debian OMAP kernel, which is not only used for N900, but also for Pandaboard, etc. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 6/6] OMAPDSS: VENC: Maintian copy of video output polarity in private data
On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote:
> The VENC driver currently relies on the omap_dss_device struct to configure
> the
> video output polarity. This makes the VENC interface driver dependent on the
> omap_dss_device struct.
>
> Make the VENC driver data maintain it's own polarity field. A panel driver
> is expected to call omapdss_venc_set_vid_out_polarity() before enabling the
> interface.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/video/omap2/dss/dss.h|2 ++
> drivers/video/omap2/dss/venc.c | 13 -
> drivers/video/omap2/dss/venc_panel.c |6 ++
> 3 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> index c17d298..b2cf5530 100644
> --- a/drivers/video/omap2/dss/dss.h
> +++ b/drivers/video/omap2/dss/dss.h
> @@ -479,6 +479,8 @@ u32 omapdss_venc_get_wss(struct omap_dss_device *dssdev);
> int omapdss_venc_set_wss(struct omap_dss_device *dssdev, u32 wss);
> void omapdss_venc_set_type(struct omap_dss_device *dssdev,
> enum omap_dss_venc_type type);
> +void omapdss_venc_set_vid_out_polarity(struct omap_dss_device *dssdev,
> + enum omap_dss_signal_level vid_out_pol);
> int venc_panel_init(void);
> void venc_panel_exit(void);
>
> diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
> index 2d90fcf..8cb372f 100644
> --- a/drivers/video/omap2/dss/venc.c
> +++ b/drivers/video/omap2/dss/venc.c
> @@ -303,6 +303,7 @@ static struct {
>
> struct omap_video_timings timings;
> enum omap_dss_venc_type type;
> + enum omap_dss_signal_level vid_out_pol;
> } venc;
>
> static inline void venc_write_reg(int idx, u32 val)
> @@ -447,7 +448,7 @@ static int venc_power_on(struct omap_dss_device *dssdev)
> else /* S-Video */
> l |= (1 << 0) | (1 << 2);
>
> - if (dssdev->phy.venc.invert_polarity == false)
> + if (venc.vid_out_pol == OMAPDSS_SIG_ACTIVE_HIGH)
> l |= 1 << 3;
Are you sure this is correct? I know practically nothing about analog
TV, but the TRM doesn't seem to say much about that bit, except it can
be used to "invert the video output". It doesn't say there's an
active/inactive level for the signal.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 3/6] OMAPDSS: DSI: Maintain copy of video mode timings in driver data
On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote: > The DSI driver currently relies on the omap_dss_device struct to receive the > video mode timings requested by the panel driver. This makes the DSI interface > driver dependent on the omap_dss_device struct. > > Make the DSI driver data maintain it's own video mode timings field. The panel > driver is expected to call omapdss_dsi_set_videomode_timings() to configure > the > video mode timings before the interface is enabled. The function takes in a > void pointer rather than a pointer to omap_dss_dsi_videomode_timings struct. > This is because this function will finally be an output op shared across > different outputs to set custom or private timings. I don't think the function should take a void * in any case. If we want to share the function, it should take a struct that perhaps contains an union of rfbi and dsi timings. But I'm not sure if there's any benefit for that... So do you see us having just one set_timings, which would take either the normal video timings, rfbi timings or dsi timings? Tomi signature.asc Description: This is a digitally signed message part
[PATCH V4 3/6] OMAPDSS: DSS: Cleanup cpu_is_xxxx checks
All the cpu_is checks have been moved to dss_init_features function providing a
much more generic and cleaner interface. The OMAP version and revision specific
initializations in various functions are cleaned and the necessary data are
moved to dss_features structure which is local to dss.c.
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/video/omap2/dss/dss.c | 114 ++---
1 file changed, 73 insertions(+), 41 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 7b1c6ac..a9cb84b 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
@@ -65,6 +66,12 @@ struct dss_reg {
static int dss_runtime_get(void);
static void dss_runtime_put(void);
+struct dss_features {
+ u16 fck_div_max;
+ int dss_fck_multiplier;
+ char *clk_name;
+};
+
static struct {
struct platform_device *pdev;
void __iomem*base;
@@ -83,6 +90,8 @@ static struct {
boolctx_valid;
u32 ctx[DSS_SZ_REGS / sizeof(u32)];
+
+ const struct dss_features *feat;
} dss;
static const char * const dss_generic_clk_source_names[] = {
@@ -91,6 +100,30 @@ static const char * const dss_generic_clk_source_names[] = {
[OMAP_DSS_CLK_SRC_FCK] = "DSS_FCK",
};
+static const struct dss_features omap24xx_dss_features __initconst = {
+ .fck_div_max= 16,
+ .dss_fck_multiplier = 2,
+ .clk_name = NULL,
+};
+
+static const struct dss_features omap34xx_dss_features __initconst = {
+ .fck_div_max= 16,
+ .dss_fck_multiplier = 2,
+ .clk_name = "dpll4_m4_ck",
+};
+
+static const struct dss_features omap3630_dss_features __initconst = {
+ .fck_div_max= 32,
+ .dss_fck_multiplier = 1,
+ .clk_name = "dpll4_m4_ck",
+};
+
+static const struct dss_features omap44xx_dss_features __initconst = {
+ .fck_div_max= 32,
+ .dss_fck_multiplier = 1,
+ .clk_name = "dpll_per_m5x2_ck",
+};
+
static inline void dss_write_reg(const struct dss_reg idx, u32 val)
{
__raw_writel(val, dss.base + idx.idx);
@@ -236,7 +269,6 @@ const char *dss_get_generic_clk_source_name(enum
omap_dss_clk_source clk_src)
return dss_generic_clk_source_names[clk_src];
}
-
void dss_dump_clocks(struct seq_file *s)
{
unsigned long dpll4_ck_rate;
@@ -259,18 +291,10 @@ void dss_dump_clocks(struct seq_file *s)
seq_printf(s, "dpll4_ck %lu\n", dpll4_ck_rate);
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- seq_printf(s, "%s (%s) = %lu / %lu = %lu\n",
- fclk_name, fclk_real_name,
- dpll4_ck_rate,
- dpll4_ck_rate / dpll4_m4_ck_rate,
- fclk_rate);
- else
- seq_printf(s, "%s (%s) = %lu / %lu * 2 = %lu\n",
- fclk_name, fclk_real_name,
- dpll4_ck_rate,
- dpll4_ck_rate / dpll4_m4_ck_rate,
- fclk_rate);
+ seq_printf(s, "%s (%s) = %lu / %lu * %d = %lu\n",
+ fclk_name, fclk_real_name, dpll4_ck_rate,
+ dpll4_ck_rate / dpll4_m4_ck_rate,
+ dss.feat->dss_fck_multiplier, fclk_rate);
} else {
seq_printf(s, "%s (%s) = %lu\n",
fclk_name, fclk_real_name,
@@ -470,7 +494,7 @@ int dss_calc_clock_div(unsigned long req_pck, struct
dss_clock_info *dss_cinfo,
unsigned long fck, max_dss_fck;
- u16 fck_div, fck_div_max = 16;
+ u16 fck_div;
int match = 0;
int min_fck_per_pck;
@@ -480,9 +504,8 @@ int dss_calc_clock_div(unsigned long req_pck, struct
dss_clock_info *dss_cinfo,
max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
fck = clk_get_rate(dss.dss_clk);
- if (req_pck == dss.cache_req_pck &&
- ((cpu_is_omap34xx() && prate == dss.cache_prate) ||
-dss.cache_dss_cinfo.fck == fck)) {
+ if (req_pck == dss.cache_req_pck && prate == dss.cache_prate &&
+ dss.cache_dss_cinfo.fck == fck) {
DSSDBG("dispc clock info found from cache.\n");
*dss_cinfo = dss.cache_dss_cinfo;
*dispc_cinfo = dss.cache_dispc_cinfo;
@@ -519,16 +542,10 @@ retry:
goto found;
} else {
- if (cpu_is_omap3630() || cpu_is_omap44xx())
-
[PATCH V4 1/6] OMAPDSS: DISPC: cleanup cpu_is_xxxx checks
All the cpu_is checks have been moved to dispc_init_features function providing
a much more generic and cleaner interface. The OMAP version and revision
specific functions and data are initialized by dispc_features structure which is
local to dispc.c.
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/video/omap2/dss/dispc.c | 428 +--
1 file changed, 273 insertions(+), 155 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5b289c5..0415845 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -81,6 +81,23 @@ struct dispc_irq_stats {
unsigned irqs[32];
};
+struct dispc_features {
+ int hp_max;
+ int vp_max;
+ int sw_max;
+ int sw_start;
+ int fp_start;
+ int bp_start;
+ int (*calc_scaling) (enum omap_channel channel,
+ const struct omap_video_timings *mgr_timings,
+ u16 width, u16 height, u16 out_width, u16 out_height,
+ enum omap_color_mode color_mode, bool *five_taps,
+ int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
+ u16 pos_x, unsigned long *core_clk);
+ unsigned long (*calc_core_clk) (enum omap_channel channel,
+ u16 width, u16 height, u16 out_width, u16 out_height);
+};
+
static struct {
struct platform_device *pdev;
void __iomem*base;
@@ -101,6 +118,8 @@ static struct {
boolctx_valid;
u32 ctx[DISPC_SZ_REGS / sizeof(u32)];
+ const struct dispc_features *feat;
+
#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
spinlock_t irq_stats_lock;
struct dispc_irq_stats irq_stats;
@@ -1939,7 +1958,18 @@ static unsigned long calc_core_clk_five_taps(enum
omap_channel channel,
return core_clk;
}
-static unsigned long calc_core_clk(enum omap_channel channel, u16 width,
+static unsigned long calc_core_clk_24xx(enum omap_channel channel, u16 width,
+ u16 height, u16 out_width, u16 out_height)
+{
+ unsigned long pclk = dispc_mgr_pclk_rate(channel);
+
+ if (height > out_height && width > out_width)
+ return pclk * 4;
+ else
+ return pclk * 2;
+}
+
+static unsigned long calc_core_clk_34xx(enum omap_channel channel, u16 width,
u16 height, u16 out_width, u16 out_height)
{
unsigned int hf, vf;
@@ -1958,25 +1988,163 @@ static unsigned long calc_core_clk(enum omap_channel
channel, u16 width,
hf = 2;
else
hf = 1;
-
if (height > out_height)
vf = 2;
else
vf = 1;
- if (cpu_is_omap24xx()) {
- if (vf > 1 && hf > 1)
- return pclk * 4;
- else
- return pclk * 2;
- } else if (cpu_is_omap34xx()) {
- return pclk * vf * hf;
- } else {
- if (hf > 1)
- return DIV_ROUND_UP(pclk, out_width) * width;
- else
- return pclk;
+ return pclk * vf * hf;
+}
+
+static unsigned long calc_core_clk_44xx(enum omap_channel channel, u16 width,
+ u16 height, u16 out_width, u16 out_height)
+{
+ unsigned long pclk = dispc_mgr_pclk_rate(channel);
+
+ if (width > out_width)
+ return DIV_ROUND_UP(pclk, out_width) * width;
+ else
+ return pclk;
+}
+
+static int dispc_ovl_calc_scaling_24xx(enum omap_channel channel,
+ const struct omap_video_timings *mgr_timings,
+ u16 width, u16 height, u16 out_width, u16 out_height,
+ enum omap_color_mode color_mode, bool *five_taps,
+ int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
+ u16 pos_x, unsigned long *core_clk)
+{
+ int error;
+ u16 in_width, in_height;
+ int min_factor = min(*decim_x, *decim_y);
+ const int maxsinglelinewidth =
+ dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+ *five_taps = false;
+
+ do {
+ in_height = DIV_ROUND_UP(height, *decim_y);
+ in_width = DIV_ROUND_UP(width, *decim_x);
+ *core_clk = dispc.feat->calc_core_clk(channel, in_width,
+ in_height, out_width, out_height);
+ error = (in_width > maxsinglelinewidth || !*core_clk ||
+ *core_clk > dispc_core_clk_rate());
+ if (error) {
+ if (*decim_x == *decim_y) {
+ *decim_x = min_factor;
+ ++*decim_y;
+ } else {
+ swap(*decim_x, *decim_y);
+ if (*decim_x < *decim_y)
+ ++*decim_x;
+ }
+ }
+
Re: [PATCH 1/6] OMAPDSS: DSI: Maintain copy of operation mode in driver data
On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote: > The DSI driver currently relies on the omap_dss_device struct to know the mode > of operation of the DSI protocol(command or video mode). This makes the DSI > interface driver dependent on the omap_dss_device struct. > > Make the DSI driver data maintain it's own operation mode field. The panel > driver is expected to call omapdss_dsi_set_operation_mode() before the > interface > is enabled. > > Signed-off-by: Archit Taneja > --- > drivers/video/omap2/displays/panel-taal.c |1 + > drivers/video/omap2/dss/dsi.c | 42 > + > include/video/omapdss.h |2 ++ > 3 files changed, 34 insertions(+), 11 deletions(-) > > diff --git a/drivers/video/omap2/displays/panel-taal.c > b/drivers/video/omap2/displays/panel-taal.c > index d220f19..649247f 100644 > --- a/drivers/video/omap2/displays/panel-taal.c > +++ b/drivers/video/omap2/displays/panel-taal.c > @@ -1063,6 +1063,7 @@ static int taal_power_on(struct omap_dss_device *dssdev) > omapdss_dsi_set_size(dssdev, dssdev->panel.timings.x_res, > dssdev->panel.timings.y_res); > omapdss_dsi_set_pixel_format(dssdev, dssdev->panel.dsi_pix_fmt); > + omapdss_dsi_set_operation_mode(dssdev, dssdev->panel.dsi_mode); Taal is always in cmd mode. Shouldn't we just use a hardcoded value here? Actually I think the same goes for the pix_fmt above. It's always the same for Taal. Tomi signature.asc Description: This is a digitally signed message part
[PATCH] usb/musb/omap2430.c Delete unused variable.
Variable ret is always evaluated as true, so we don't need to check it.
Signed-off-by: Matthias Brugger
---
drivers/usb/musb/omap2430.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..2d207c6 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -140,7 +140,6 @@ static void omap2430_musb_set_vbus(struct musb *musb, int
is_on)
struct usb_otg *otg = musb->xceiv->otg;
u8 devctl;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
- int ret = 1;
/* HDRC controls CPEN, but beware current surges during device
* connect. They can trigger transient overcurrent conditions
* that must be ignored.
@@ -164,12 +163,11 @@ static void omap2430_musb_set_vbus(struct musb *musb, int
is_on)
if (time_after(jiffies, timeout)) {
dev_err(musb->controller,
"configured as A device timeout");
- ret = -EINVAL;
break;
}
}
- if (ret && otg->set_vbus)
+ if (otg->set_vbus)
otg_set_vbus(otg, 1);
} else {
musb->is_active = 1;
--
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] usb/musb/omap2430.c Delete unused variable
On Thu, Aug 16, 2012 at 12:22:14PM +0200, Matthias Brugger wrote: > Signed-off-by: Matthias Brugger I need a commit log, even if obvious. -- balbi signature.asc Description: Digital signature
Re: [git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver
Moi, On Wed, Aug 15, 2012 at 10:46:43PM +0300, Timo Kokkonen wrote: > Long time no see. Indeed! Better late than never I guess. :) > On 08/15/12 19:06, Sakari Ailus wrote: > > Heippa, > > > > Thanks for the patch! I know Mauro has already applied this so any changes > > would make a separate patch. > > > > Patches are cheap :) I'll have also couple of changes from Sean's comments. > > > I have tested this up to the point I can see that the IR LED blinks --- > > using my phone's camera. :-) But I have no receivers so the testing ends to > > this. > > Thanks for your thorough review and testing. You're welcome. It's nice to see people working on the N900 support. ;) > > On Mon, Aug 13, 2012 at 09:53:45PM +0200, Mauro Carvalho Chehab wrote: > >> This is an automatic generated email to let you know that the following > >> patch were queued at the > >> http://git.linuxtv.org/media_tree.git tree: > >> > >> Subject: [media] media: rc: Introduce RX51 IR transmitter driver > >> Author: Timo Kokkonen > >> Date:Fri Aug 10 06:16:36 2012 -0300 > >> > >> This is the driver for the IR transmitter diode found on the Nokia > >> N900 (also known as RX51) device. The driver is mostly the same as > >> found in the original 2.6.28 based kernel that comes with the device. > >> > >> The following modifications have been made compared to the original > >> driver version: > >> > >> - Adopt to the changes that has happen in the kernel during the past > >> five years, such as the change in the include paths > >> > >> - The OMAP DM-timers require much more care nowadays. The timers need > >> to be enabled and disabled or otherwise many actions fail. Timers > >> must not be freed without first stopping them or otherwise the timer > >> cannot be requested again. > >> > >> The code has been tested with sending IR codes with N900 device > >> running Debian userland. The device receiving the codes was Anysee > >> DVB-C USB receiver. > > > > Just a general question: how much this driver actually depends on the N900? > > I can see there's a dependency to OMAP DM timers, but couldn't you use the > > same driver if you just wired the IR LED there? Even the timer configuration > > is there, so it looks a lot more generic than N900-specific. > > > > Yeah, I was thinking that there are no other boards that have an IR > diode connected to the PWM timer pin. But that doesn't stop anyone from > soldering a diode one to his/her board. > > >> Signed-off-by: Timo Kokkonen > >> Cc: Tony Lindgren > >> Cc: linux-omap@vger.kernel.org > >> Cc: Sakari Ailus > >> Signed-off-by: Mauro Carvalho Chehab > >> > >> drivers/media/rc/Kconfig | 10 + > >> drivers/media/rc/Makefile |1 + > >> drivers/media/rc/ir-rx51.c | 496 > >> > >> include/media/ir-rx51.h| 10 + > >> 4 files changed, 517 insertions(+), 0 deletions(-) > >> > >> --- > >> > >> http://git.linuxtv.org/media_tree.git?a=commitdiff;h=c332e8472d7db67766bcad33390c607fdd9ac5bc > >> > >> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig > >> index 64be610..016f9ab 100644 > >> --- a/drivers/media/rc/Kconfig > >> +++ b/drivers/media/rc/Kconfig > >> @@ -287,6 +287,16 @@ config IR_TTUSBIR > >> To compile this driver as a module, choose M here: the module will > >> be called ttusbir. > >> > >> +config IR_RX51 > >> + tristate "Nokia N900 IR transmitter diode > >> + depends on MACH_NOKIA_RX51 && OMAP_DM_TIMER > > > > You also should depend on LIRC. > > Yes. And if one had the diode in some other board than RX51, maybe this > wouldn't need to depend on MACH_NOKIA_RX51 either. > > ... > > > Which gave me an idea. We have this new PWM subsystem that I know > nothing about. If the omap timer PWM routines were exposed through this > API, we could modify this driver to a generic PWM lirc driver. I don't > know how well the PWM api suits for that purpose, but it could be an > interesting idea.. :) Sounds like an excellent idea. If the PWM subsystem couldn't be used for this it'd be very valuable input for the design of that API. That's something for future though, as I guess the OMAP DM timers aren't yet supported by the PWM framework. This pull req has support for many sub-archs but not for OMAPs. :I http://www.spinics.net/lists/arm-kernel/msg180746.html> It might not make sense to rename the driver before moving to PWM API but a note saying it can be used on any OMAP ? for the same would be nice. > >> + ---help--- > >> + Say Y or M here if you want to enable support for the IR > >> + transmitter diode built in the Nokia N900 (RX51) device. > >> + > >> + The driver uses omap DM timers for gereating the carrier > > > > s/gereating/renerating/ > > > > Uh oh, will fix.. > > >> + wave and pulses. > >> + > >> config RC_LOOPBACK > >>tristate "Remote Control Loopback Driver" > >>depends on RC_CORE > >> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Mak
[PATCH] usb/musb/omap2430.c Delete unused variable
Signed-off-by: Matthias Brugger
---
drivers/usb/musb/omap2430.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..2d207c6 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -140,7 +140,6 @@ static void omap2430_musb_set_vbus(struct musb *musb, int
is_on)
struct usb_otg *otg = musb->xceiv->otg;
u8 devctl;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
- int ret = 1;
/* HDRC controls CPEN, but beware current surges during device
* connect. They can trigger transient overcurrent conditions
* that must be ignored.
@@ -164,12 +163,11 @@ static void omap2430_musb_set_vbus(struct musb *musb, int
is_on)
if (time_after(jiffies, timeout)) {
dev_err(musb->controller,
"configured as A device timeout");
- ret = -EINVAL;
break;
}
}
- if (ret && otg->set_vbus)
+ if (otg->set_vbus)
otg_set_vbus(otg, 1);
} else {
musb->is_active = 1;
--
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 v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Thu, Aug 16, 2012 at 03:56:42, Paul Walmsley wrote: > Hi > > On Mon, 9 Jul 2012, Tony Lindgren wrote: > > > Below (untested) is what could be done in the short term. > > That's fine with me. Do you want to queue it or do you want me to queue > it? > > > Heh these CK_ defines are now running out of the u16 cpu_mask. > > > > They really should be replaced with SoC specific lists of clocks > > rather than bloating the cpu_mask and repeating it for every clock > > that's compiled in for 800+ times. > > Frankly, an extra 1.6KB -- uncompressed -- is pretty low on my list of > bloat concerns for multi-OMAP kernels. If it were up to me, I'd just > change it to a u32 and be done with the problem for the foreseeable > future. > > > I wonder if we could #define CK_OMAP_DUMMY 0 that's always set > > for non-shared clocks if they only get set in some *_data.c > > file in a unique way? > > > > Paul got any better ideas? > > Aside from using u32? Not really. As we've discussed in the past, at > some point we should convert the clock initialization to using some kind > of per-SoC list. But it doesn't seem worth spending too much time on that > while the common clock framework conversion is higher priority. > > This reminds me for AM33xx clock-tree migration to common-clock framework, so just wanted to update on this, I have already converted the clock-tree to common-clock fw, on top of Rajendra's repository. Now waiting on Rajendra for his next series... 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 v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Paul Walmsley [120815 15:27]: > Hi > > On Mon, 9 Jul 2012, Tony Lindgren wrote: > > > Below (untested) is what could be done in the short term. > > That's fine with me. Do you want to queue it or do you want me to queue > it? Probably best for you to take it along with other related patches. > > Heh these CK_ defines are now running out of the u16 cpu_mask. > > > > They really should be replaced with SoC specific lists of clocks > > rather than bloating the cpu_mask and repeating it for every clock > > that's compiled in for 800+ times. > > Frankly, an extra 1.6KB -- uncompressed -- is pretty low on my list of > bloat concerns for multi-OMAP kernels. If it were up to me, I'd just > change it to a u32 and be done with the problem for the foreseeable > future. And then we're wasting that 1.6KB.. > > I wonder if we could #define CK_OMAP_DUMMY 0 that's always set > > for non-shared clocks if they only get set in some *_data.c > > file in a unique way? > > > > Paul got any better ideas? > > Aside from using u32? Not really. As we've discussed in the past, at > some point we should convert the clock initialization to using some kind > of per-SoC list. But it doesn't seem worth spending too much time on that > while the common clock framework conversion is higher priority. Right, let's do the ifdef else thing then. Regards, Tony -- 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: Fate of OMAP3-Touchbook board
* Radek Pilar [120815 14:00]: > Hello, > a few months ago, Always Innovating - a company behind their OMAP3 based > product Touchbook basically stopped production. I've been porting some > specific drivers for current kernels since then and I'd like to push at > least some of them to the mainline. > However, I found a bug in mainline that prevents this device from > booting - and looks like noone has reported it for a few months. > So, I'd like to ask - do you want to keep this board in mainline (in > this case, I can send a few patches adding few drivers (backlight, > accelerometer, soundcard, keyboard). Or do you want to remove it from > the mainline altogether? The fix should be posted for -rc cycle. Minimal patches for the board-*.c files are OK, but we should put most effort making things usable with device tree based booting. Regards, Tony -- 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] regulator: twl-regulator: fix up VINTANA1/VINTANA2
On Wednesday 15 August 2012 03:40 AM, Aaro Koskinen wrote: It seems commit 2098e95ce9bb039ff2e7bf836df358d18a176139 (regulator: twl: adapt twl-regulator driver to dt) accidentally deleted VINTANA1. Also the same commit defines VINTANA2 twice with TWL4030_ADJUSTABLE_LDO and TWL4030_FIXED_LDO. This patch changes the fixed one to be VINTANA1. Thanks for the fix, the commit does seem to have mixed up things. Acked-by: Rajendra Nayak -- 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/6] OMAPDSS: VENC: Maintian copy of video output polarity in private data
The VENC driver currently relies on the omap_dss_device struct to configure the
video output polarity. This makes the VENC interface driver dependent on the
omap_dss_device struct.
Make the VENC driver data maintain it's own polarity field. A panel driver
is expected to call omapdss_venc_set_vid_out_polarity() before enabling the
interface.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dss.h|2 ++
drivers/video/omap2/dss/venc.c | 13 -
drivers/video/omap2/dss/venc_panel.c |6 ++
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index c17d298..b2cf5530 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -479,6 +479,8 @@ u32 omapdss_venc_get_wss(struct omap_dss_device *dssdev);
int omapdss_venc_set_wss(struct omap_dss_device *dssdev, u32 wss);
void omapdss_venc_set_type(struct omap_dss_device *dssdev,
enum omap_dss_venc_type type);
+void omapdss_venc_set_vid_out_polarity(struct omap_dss_device *dssdev,
+ enum omap_dss_signal_level vid_out_pol);
int venc_panel_init(void);
void venc_panel_exit(void);
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 2d90fcf..8cb372f 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -303,6 +303,7 @@ static struct {
struct omap_video_timings timings;
enum omap_dss_venc_type type;
+ enum omap_dss_signal_level vid_out_pol;
} venc;
static inline void venc_write_reg(int idx, u32 val)
@@ -447,7 +448,7 @@ static int venc_power_on(struct omap_dss_device *dssdev)
else /* S-Video */
l |= (1 << 0) | (1 << 2);
- if (dssdev->phy.venc.invert_polarity == false)
+ if (venc.vid_out_pol == OMAPDSS_SIG_ACTIVE_HIGH)
l |= 1 << 3;
venc_write_reg(VENC_OUTPUT_CONTROL, l);
@@ -639,6 +640,16 @@ void omapdss_venc_set_type(struct omap_dss_device *dssdev,
mutex_unlock(&venc.venc_lock);
}
+void omapdss_venc_set_vid_out_polarity(struct omap_dss_device *dssdev,
+ enum omap_dss_signal_level vid_out_pol)
+{
+ mutex_lock(&venc.venc_lock);
+
+ venc.vid_out_pol = vid_out_pol;
+
+ mutex_unlock(&venc.venc_lock);
+}
+
static int __init venc_init_display(struct omap_dss_device *dssdev)
{
DSSDBG("init_display\n");
diff --git a/drivers/video/omap2/dss/venc_panel.c
b/drivers/video/omap2/dss/venc_panel.c
index ef21361..a8117d0 100644
--- a/drivers/video/omap2/dss/venc_panel.c
+++ b/drivers/video/omap2/dss/venc_panel.c
@@ -118,6 +118,7 @@ static void venc_panel_remove(struct omap_dss_device
*dssdev)
static int venc_panel_enable(struct omap_dss_device *dssdev)
{
int r;
+ enum omap_dss_signal_level vid_out_pol;
dev_dbg(&dssdev->dev, "venc_panel_enable\n");
@@ -131,6 +132,11 @@ static int venc_panel_enable(struct omap_dss_device
*dssdev)
omapdss_venc_set_timings(dssdev, &dssdev->panel.timings);
omapdss_venc_set_type(dssdev, dssdev->phy.venc.type);
+ vid_out_pol = dssdev->phy.venc.invert_polarity ?
+ OMAPDSS_SIG_ACTIVE_LOW : OMAPDSS_SIG_ACTIVE_HIGH;
+
+ omapdss_venc_set_vid_out_polarity(dssdev, vid_out_pol);
+
r = omapdss_venc_display_enable(dssdev);
if (r)
goto err;
--
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 5/6] OMAPDSS: VENC: Maintain copy of venc type in driver data
The VENC driver currently relies on the omap_dss_device struct to configure the
venc type. This makes the VENC interface driver dependent on the omap_dss_device
struct.
Make the VENC driver data maintain it's own 'venc type' field. A panel driver
is expected to call omapdss_venc_set_type() before enabling the interface or
changing the type via display sysfs attributes.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dss.h|2 ++
drivers/video/omap2/dss/venc.c | 15 +--
drivers/video/omap2/dss/venc_panel.c |2 ++
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index f919dc8..c17d298 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -477,6 +477,8 @@ int omapdss_venc_check_timings(struct omap_dss_device
*dssdev,
struct omap_video_timings *timings);
u32 omapdss_venc_get_wss(struct omap_dss_device *dssdev);
int omapdss_venc_set_wss(struct omap_dss_device *dssdev, u32 wss);
+void omapdss_venc_set_type(struct omap_dss_device *dssdev,
+ enum omap_dss_venc_type type);
int venc_panel_init(void);
void venc_panel_exit(void);
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index d96025e..2d90fcf 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -302,6 +302,7 @@ static struct {
struct clk *tv_dac_clk;
struct omap_video_timings timings;
+ enum omap_dss_venc_type type;
} venc;
static inline void venc_write_reg(int idx, u32 val)
@@ -436,12 +437,12 @@ static int venc_power_on(struct omap_dss_device *dssdev)
venc_reset();
venc_write_config(venc_timings_to_config(&venc.timings));
- dss_set_venc_output(dssdev->phy.venc.type);
+ dss_set_venc_output(venc.type);
dss_set_dac_pwrdn_bgz(1);
l = 0;
- if (dssdev->phy.venc.type == OMAP_DSS_VENC_TYPE_COMPOSITE)
+ if (venc.type == OMAP_DSS_VENC_TYPE_COMPOSITE)
l |= 1 << 1;
else /* S-Video */
l |= (1 << 0) | (1 << 2);
@@ -628,6 +629,16 @@ err:
return r;
}
+void omapdss_venc_set_type(struct omap_dss_device *dssdev,
+ enum omap_dss_venc_type type)
+{
+ mutex_lock(&venc.venc_lock);
+
+ venc.type = type;
+
+ mutex_unlock(&venc.venc_lock);
+}
+
static int __init venc_init_display(struct omap_dss_device *dssdev)
{
DSSDBG("init_display\n");
diff --git a/drivers/video/omap2/dss/venc_panel.c
b/drivers/video/omap2/dss/venc_panel.c
index 8096369..ef21361 100644
--- a/drivers/video/omap2/dss/venc_panel.c
+++ b/drivers/video/omap2/dss/venc_panel.c
@@ -68,6 +68,7 @@ static ssize_t display_output_type_store(struct device *dev,
if (dssdev->phy.venc.type != new_type) {
dssdev->phy.venc.type = new_type;
+ omapdss_venc_set_type(dssdev, new_type);
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE) {
omapdss_venc_display_disable(dssdev);
omapdss_venc_display_enable(dssdev);
@@ -128,6 +129,7 @@ static int venc_panel_enable(struct omap_dss_device *dssdev)
}
omapdss_venc_set_timings(dssdev, &dssdev->panel.timings);
+ omapdss_venc_set_type(dssdev, dssdev->phy.venc.type);
r = omapdss_venc_display_enable(dssdev);
if (r)
--
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 4/6] OMAPDSS: RFBI: Maitain copy of rfbi timings in driver data
The RFBI driver currently relies on the omap_dss_device struct to receive the
rfbi specific timings requested by the panel driver. This makes the RFBI
interface driver dependent on the omap_dss_device struct.
Make the RFBI driver data maintain it's own rfbi specific timings field. The
panel driver is expected to call omapdss_rfbi_set_interface_timings() to
configure the rfbi timings before the interface is enabled. The function takes
a void pointer rather than a pointer to rfbi_timings struct. This is because
this function will finally be an output op shared across different outputs to
set custom or private timings.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-n8x0.c |2 ++
drivers/video/omap2/dss/rfbi.c| 14 +++---
include/video/omapdss.h |2 ++
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-n8x0.c
b/drivers/video/omap2/displays/panel-n8x0.c
index 3ffd987..14adc1d 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -307,6 +307,8 @@ static int n8x0_panel_power_on(struct omap_dss_device
*dssdev)
dssdev->panel.timings.y_res);
omapdss_rfbi_set_pixel_size(dssdev, dssdev->ctrl.pixel_size);
omapdss_rfbi_set_data_lines(dssdev, dssdev->phy.rfbi.data_lines);
+ omapdss_rfbi_set_interface_timings(dssdev,
+ (void *) &dssdev->ctrl.rfbi_timings);
r = omapdss_rfbi_display_enable(dssdev);
if (r)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 698d5b9..b5b0bc6 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -115,6 +115,7 @@ static struct {
struct omap_video_timings timings;
int pixel_size;
int data_lines;
+ struct rfbi_timings intf_timings;
} rfbi;
static inline void rfbi_write_reg(const struct rfbi_reg idx, u32 val)
@@ -799,6 +800,15 @@ void omapdss_rfbi_set_data_lines(struct omap_dss_device
*dssdev, int data_lines)
}
EXPORT_SYMBOL(omapdss_rfbi_set_data_lines);
+void omapdss_rfbi_set_interface_timings(struct omap_dss_device *dssdev,
+ void *timings)
+{
+ struct rfbi_timings *t = (struct rfbi_timings *) timings;
+
+ rfbi.intf_timings = *t;
+}
+EXPORT_SYMBOL(omapdss_rfbi_set_interface_timings);
+
static void rfbi_dump_regs(struct seq_file *s)
{
#define DUMPREG(r) seq_printf(s, "%-35s %08x\n", #r, rfbi_read_reg(r))
@@ -907,9 +917,7 @@ int omapdss_rfbi_display_enable(struct omap_dss_device
*dssdev)
rfbi_configure(dssdev->phy.rfbi.channel, rfbi.pixel_size,
rfbi.data_lines);
- rfbi_set_timings(dssdev->phy.rfbi.channel,
-&dssdev->ctrl.rfbi_timings);
-
+ rfbi_set_timings(dssdev->phy.rfbi.channel, &rfbi.intf_timings);
return 0;
err1:
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index faac986..91eba93 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -765,5 +765,7 @@ void omapdss_rfbi_set_pixel_size(struct omap_dss_device
*dssdev,
int pixel_size);
void omapdss_rfbi_set_data_lines(struct omap_dss_device *dssdev,
int data_lines);
+void omapdss_rfbi_set_interface_timings(struct omap_dss_device *dssdev,
+ void *timings);
#endif
--
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 3/6] OMAPDSS: DSI: Maintain copy of video mode timings in driver data
The DSI driver currently relies on the omap_dss_device struct to receive the
video mode timings requested by the panel driver. This makes the DSI interface
driver dependent on the omap_dss_device struct.
Make the DSI driver data maintain it's own video mode timings field. The panel
driver is expected to call omapdss_dsi_set_videomode_timings() to configure the
video mode timings before the interface is enabled. The function takes in a
void pointer rather than a pointer to omap_dss_dsi_videomode_timings struct.
This is because this function will finally be an output op shared across
different outputs to set custom or private timings.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dsi.c | 52 -
include/video/omapdss.h |2 ++
2 files changed, 38 insertions(+), 16 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 62549f6..6c2c746 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -336,6 +336,7 @@ struct dsi_data {
struct omap_video_timings timings;
enum omap_dss_dsi_pixel_format pix_fmt;
enum omap_dss_dsi_mode mode;
+ struct omap_dss_dsi_videomode_timings vm_timings;
};
struct dsi_packet_sent_handler_data {
@@ -2366,7 +2367,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
/* DDR_CLK_ALWAYS_ON */
REG_FLD_MOD(dsidev, DSI_CLK_CTRL,
- dssdev->panel.dsi_vm_timings.ddr_clk_always_on, 13, 13);
+ dsi->vm_timings.ddr_clk_always_on, 13, 13);
}
dsi->ulps_enabled = false;
@@ -2688,6 +2689,7 @@ void omapdss_dsi_vc_enable_hs(struct omap_dss_device
*dssdev, int channel,
bool enable)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
DSSDBG("dsi_vc_enable_hs(%d, %d)\n", channel, enable);
@@ -2704,7 +2706,7 @@ void omapdss_dsi_vc_enable_hs(struct omap_dss_device
*dssdev, int channel,
dsi_force_tx_stop_mode_io(dsidev);
/* start the DDR clock by sending a NULL packet */
- if (dssdev->panel.dsi_vm_timings.ddr_clk_always_on && enable)
+ if (dsi->vm_timings.ddr_clk_always_on && enable)
dsi_vc_send_null(dssdev, channel);
}
EXPORT_SYMBOL(omapdss_dsi_vc_enable_hs);
@@ -3638,8 +3640,9 @@ static void dsi_config_vp_num_line_buffers(struct
omap_dss_device *dssdev)
static void dsi_config_vp_sync_events(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
- bool vsync_end = dssdev->panel.dsi_vm_timings.vp_vsync_end;
- bool hsync_end = dssdev->panel.dsi_vm_timings.vp_hsync_end;
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ bool vsync_end = dsi->vm_timings.vp_vsync_end;
+ bool hsync_end = dsi->vm_timings.vp_hsync_end;
u32 r;
r = dsi_read_reg(dsidev, DSI_CTRL);
@@ -3656,10 +3659,11 @@ static void dsi_config_vp_sync_events(struct
omap_dss_device *dssdev)
static void dsi_config_blanking_modes(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
- int blanking_mode = dssdev->panel.dsi_vm_timings.blanking_mode;
- int hfp_blanking_mode = dssdev->panel.dsi_vm_timings.hfp_blanking_mode;
- int hbp_blanking_mode = dssdev->panel.dsi_vm_timings.hbp_blanking_mode;
- int hsa_blanking_mode = dssdev->panel.dsi_vm_timings.hsa_blanking_mode;
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ int blanking_mode = dsi->vm_timings.blanking_mode;
+ int hfp_blanking_mode = dsi->vm_timings.hfp_blanking_mode;
+ int hbp_blanking_mode = dsi->vm_timings.hbp_blanking_mode;
+ int hsa_blanking_mode = dsi->vm_timings.hsa_blanking_mode;
u32 r;
/*
@@ -3992,14 +3996,14 @@ static void dsi_proto_timings(struct omap_dss_device
*dssdev)
if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
/* TODO: Implement a video mode check_timings function */
- int hsa = dssdev->panel.dsi_vm_timings.hsa;
- int hfp = dssdev->panel.dsi_vm_timings.hfp;
- int hbp = dssdev->panel.dsi_vm_timings.hbp;
- int vsa = dssdev->panel.dsi_vm_timings.vsa;
- int vfp = dssdev->panel.dsi_vm_timings.vfp;
- int vbp = dssdev->panel.dsi_vm_timings.vbp;
- int window_sync = dssdev->panel.dsi_vm_timings.window_sync;
- bool hsync_end = dssdev->panel.dsi_vm_timings.vp_hsync_end;
+ int hsa = dsi->vm_timings.hsa;
+ int hfp = dsi->vm_timings.hfp;
+ int hbp = dsi->vm_timings.hbp;
+ int vsa = dsi->vm_timings.vsa;
+ int vfp = dsi->vm_timings.vfp;
+ int vbp = dsi->vm_timings.
[PATCH 2/6] OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings
The struct omap_dss_dsi_videomode_data holds fields which need to be configured
for DSI to operate in video mode. Rename the struct to dsi_videomode_timings.
One reason to do this is because most of the fields in the struct are timings
related. The other reason is to create a generic op for output specific
timings. This generic op can be considered as a way to set custom or private
timings for the output.
In the case of OMAP, DSI and RFBI require some more timings apart from the
regular DISPC timings. The structs omap_dss_videomode_timings and rfbi_timings
can be considered as these output specific timings respectively.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dsi.c | 32
include/video/omapdss.h |4 ++--
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index c10c8cb..62549f6 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -2366,7 +2366,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
/* DDR_CLK_ALWAYS_ON */
REG_FLD_MOD(dsidev, DSI_CLK_CTRL,
- dssdev->panel.dsi_vm_data.ddr_clk_always_on, 13, 13);
+ dssdev->panel.dsi_vm_timings.ddr_clk_always_on, 13, 13);
}
dsi->ulps_enabled = false;
@@ -2704,7 +2704,7 @@ void omapdss_dsi_vc_enable_hs(struct omap_dss_device
*dssdev, int channel,
dsi_force_tx_stop_mode_io(dsidev);
/* start the DDR clock by sending a NULL packet */
- if (dssdev->panel.dsi_vm_data.ddr_clk_always_on && enable)
+ if (dssdev->panel.dsi_vm_timings.ddr_clk_always_on && enable)
dsi_vc_send_null(dssdev, channel);
}
EXPORT_SYMBOL(omapdss_dsi_vc_enable_hs);
@@ -3638,8 +3638,8 @@ static void dsi_config_vp_num_line_buffers(struct
omap_dss_device *dssdev)
static void dsi_config_vp_sync_events(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
- bool vsync_end = dssdev->panel.dsi_vm_data.vp_vsync_end;
- bool hsync_end = dssdev->panel.dsi_vm_data.vp_hsync_end;
+ bool vsync_end = dssdev->panel.dsi_vm_timings.vp_vsync_end;
+ bool hsync_end = dssdev->panel.dsi_vm_timings.vp_hsync_end;
u32 r;
r = dsi_read_reg(dsidev, DSI_CTRL);
@@ -3656,10 +3656,10 @@ static void dsi_config_vp_sync_events(struct
omap_dss_device *dssdev)
static void dsi_config_blanking_modes(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
- int blanking_mode = dssdev->panel.dsi_vm_data.blanking_mode;
- int hfp_blanking_mode = dssdev->panel.dsi_vm_data.hfp_blanking_mode;
- int hbp_blanking_mode = dssdev->panel.dsi_vm_data.hbp_blanking_mode;
- int hsa_blanking_mode = dssdev->panel.dsi_vm_data.hsa_blanking_mode;
+ int blanking_mode = dssdev->panel.dsi_vm_timings.blanking_mode;
+ int hfp_blanking_mode = dssdev->panel.dsi_vm_timings.hfp_blanking_mode;
+ int hbp_blanking_mode = dssdev->panel.dsi_vm_timings.hbp_blanking_mode;
+ int hsa_blanking_mode = dssdev->panel.dsi_vm_timings.hsa_blanking_mode;
u32 r;
/*
@@ -3992,14 +3992,14 @@ static void dsi_proto_timings(struct omap_dss_device
*dssdev)
if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
/* TODO: Implement a video mode check_timings function */
- int hsa = dssdev->panel.dsi_vm_data.hsa;
- int hfp = dssdev->panel.dsi_vm_data.hfp;
- int hbp = dssdev->panel.dsi_vm_data.hbp;
- int vsa = dssdev->panel.dsi_vm_data.vsa;
- int vfp = dssdev->panel.dsi_vm_data.vfp;
- int vbp = dssdev->panel.dsi_vm_data.vbp;
- int window_sync = dssdev->panel.dsi_vm_data.window_sync;
- bool hsync_end = dssdev->panel.dsi_vm_data.vp_hsync_end;
+ int hsa = dssdev->panel.dsi_vm_timings.hsa;
+ int hfp = dssdev->panel.dsi_vm_timings.hfp;
+ int hbp = dssdev->panel.dsi_vm_timings.hbp;
+ int vsa = dssdev->panel.dsi_vm_timings.vsa;
+ int vfp = dssdev->panel.dsi_vm_timings.vfp;
+ int vbp = dssdev->panel.dsi_vm_timings.vbp;
+ int window_sync = dssdev->panel.dsi_vm_timings.window_sync;
+ bool hsync_end = dssdev->panel.dsi_vm_timings.vp_hsync_end;
struct omap_video_timings *timings = &dsi->timings;
int bpp = dsi_get_pixel_size(dsi->pix_fmt);
int tl, t_he, width_bytes;
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index ef14ac5..363235c 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -243,7 +243,7 @@ void rfbi_bus_unlock(void);
/* DSI */
-struct omap_dss_dsi_videomode_data {
+struct omap_dss_dsi_video
[PATCH 1/6] OMAPDSS: DSI: Maintain copy of operation mode in driver data
The DSI driver currently relies on the omap_dss_device struct to know the mode
of operation of the DSI protocol(command or video mode). This makes the DSI
interface driver dependent on the omap_dss_device struct.
Make the DSI driver data maintain it's own operation mode field. The panel
driver is expected to call omapdss_dsi_set_operation_mode() before the interface
is enabled.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-taal.c |1 +
drivers/video/omap2/dss/dsi.c | 42 +
include/video/omapdss.h |2 ++
3 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index d220f19..649247f 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -1063,6 +1063,7 @@ static int taal_power_on(struct omap_dss_device *dssdev)
omapdss_dsi_set_size(dssdev, dssdev->panel.timings.x_res,
dssdev->panel.timings.y_res);
omapdss_dsi_set_pixel_format(dssdev, dssdev->panel.dsi_pix_fmt);
+ omapdss_dsi_set_operation_mode(dssdev, dssdev->panel.dsi_mode);
r = omapdss_dsi_display_enable(dssdev);
if (r) {
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 8f94cb80..c10c8cb 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -335,6 +335,7 @@ struct dsi_data {
struct dss_lcd_mgr_config mgr_config;
struct omap_video_timings timings;
enum omap_dss_dsi_pixel_format pix_fmt;
+ enum omap_dss_dsi_mode mode;
};
struct dsi_packet_sent_handler_data {
@@ -2362,7 +2363,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
dsi_cio_timings(dsidev);
- if (dssdev->panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
/* DDR_CLK_ALWAYS_ON */
REG_FLD_MOD(dsidev, DSI_CLK_CTRL,
dssdev->panel.dsi_vm_data.ddr_clk_always_on, 13, 13);
@@ -3609,9 +3610,10 @@ static void dsi_set_hs_tx_timeout(struct platform_device
*dsidev,
static void dsi_config_vp_num_line_buffers(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
int num_line_buffers;
- if (dssdev->panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
int bpp = dsi_get_pixel_size(dsi->pix_fmt);
unsigned line_buf_size = dsi_get_line_buf_size(dsidev);
@@ -3909,7 +3911,7 @@ static int dsi_proto_config(struct omap_dss_device
*dssdev)
dsi_config_vp_num_line_buffers(dssdev);
- if (dssdev->panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
dsi_config_vp_sync_events(dssdev);
dsi_config_blanking_modes(dssdev);
dsi_config_cmd_mode_interleaving(dssdev);
@@ -3988,7 +3990,7 @@ static void dsi_proto_timings(struct omap_dss_device
*dssdev)
DSSDBG("enter_hs_mode_lat %u, exit_hs_mode_lat %u\n",
enter_hs_mode_lat, exit_hs_mode_lat);
-if (dssdev->panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
/* TODO: Implement a video mode check_timings function */
int hsa = dssdev->panel.dsi_vm_data.hsa;
int hfp = dssdev->panel.dsi_vm_data.hfp;
@@ -4113,7 +4115,7 @@ int dsi_enable_video_output(struct omap_dss_device
*dssdev, int channel)
u16 word_count;
int r;
- if (dssdev->panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
switch (dsi->pix_fmt) {
case OMAP_DSS_DSI_FMT_RGB888:
data_type = MIPI_DSI_PACKED_PIXEL_STREAM_24;
@@ -4149,7 +4151,7 @@ int dsi_enable_video_output(struct omap_dss_device
*dssdev, int channel)
r = dss_mgr_enable(dssdev->manager);
if (r) {
- if (dssdev->panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
dsi_if_enable(dsidev, false);
dsi_vc_enable(dsidev, channel, false);
}
@@ -4164,8 +4166,9 @@ EXPORT_SYMBOL(dsi_enable_video_output);
void dsi_disable_video_output(struct omap_dss_device *dssdev, int channel)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- if (dssdev->panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
dsi_if_enable(dsidev, false);
[PATCH 0/6] OMAPDSS: Pass output specific parameters from panel driver to output
This is a continuation of the series below: http://marc.info/?l=linux-omap&m=134381744304672&w=2 This series tries to pass output specific parameters from panel driver to the connected output. These are basically parameters which can't really be shared across different outputs. An attempt has been made to have similar looking functions for setting DSI videomode timings and RFBI timings. But all the other parameters in the series take output specific arguments. After this series, the interface drivers look more independent of omap_dss_device. It'll now be easier to add outputs as another DSS entity, and pass them rather than passing omap_dss_device from panel drivers to output/interface drivers. git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git pass_output_specific Tested on 4430SDP and 3430SDP Archit Taneja (6): OMAPDSS: DSI: Maintain copy of operation mode in driver data OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings OMAPDSS: DSI: Maintain copy of video mode timings in driver data OMAPDSS: RFBI: Maitain copy of rfbi timings in driver data OMAPDSS: VENC: Maintain copy of venc type in driver data OMAPDSS: VENC: Maintian copy of video output polarity in private data drivers/video/omap2/displays/panel-n8x0.c |2 + drivers/video/omap2/displays/panel-taal.c |1 + drivers/video/omap2/dss/dsi.c | 94 - drivers/video/omap2/dss/dss.h |4 ++ drivers/video/omap2/dss/rfbi.c| 14 - drivers/video/omap2/dss/venc.c| 28 - drivers/video/omap2/dss/venc_panel.c |8 +++ include/video/omapdss.h | 10 ++- 8 files changed, 126 insertions(+), 35 deletions(-) -- 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
