Re: [PATCH RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.
Hi Balbi,
On Fri, Feb 1, 2013 at 11:52 AM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Fri, Feb 1, 2013 at 10:51 AM, kishon wrote:
>> Hi,
>>
>>
>> On Thursday 31 January 2013 09:08 PM, Felipe Balbi wrote:
>>>
>>> On Thu, Jan 31, 2013 at 09:00:37PM +0530, Vivek Gautam wrote:
Hi Felipe,
On Thu, Jan 31, 2013 at 8:55 PM, Felipe Balbi wrote:
>
> Hi,
>
> On Thu, Jan 31, 2013 at 08:53:27PM +0530, Vivek Gautam wrote:
Moreover, SoCs having multiple dwc3 controllers will have multiple
PHYs, which eventually be added using usb_add_phy_dev(), and not
using usb_add_phy(). So each dwc3 controller won't be able to
get PHYs by simply calling devm_usb_get_phy() also.
>>>
>>>
>>> No. We have added usb_get_phy_dev() for that purpose in the case of
>>> non-dt.
>>> I think, instead you can have a patch to use devm_usb_get_phy_dev()
>>> here and
>>> in exynos platform specific code use usb_bind_phy() to bind the phy
>>> and
>>> controller till you change it to dt.
>>>
>>
>> We have dt support for dwc3-exynos, in such case we should go ahead
>> with
>> of_platform_populate(), right ?
>> But if when i use of_platform_populate() i will not be able to set
>> dma_mask to dwc3->dev. :-(
>>
>>
>> You can do something like this
>>
>> static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
>>
>> static int dwc3_exynos_set_dmamask(struct device *dev, void *c)
>> {
>> dev->dma_mask = &dwc3_exynos_dma_mask;
>>
>> return 0;
>> }
>>
>> And in your probe after of_platform_populate, you can add
>>
>> device_for_each_child(&pdev->dev, NULL, dwc3_exynos_set_dmamask);
>>
>> Here pdev is the platform device of dwc3-exynos. By this way all the
>> children of dwc3-exynos will have dma_mask set to the required value.
>>
>
> Nice idea, thanks :-)
> hmm.. so i can patch this now, and get things working ;-)
>
If this is fine with you shall i go ahead and post a patch for the same ? ;-)
>> I'm not sure if there is any other better way to achieve the same (without
>> patching of.c ;-))
>>
>
--
Thanks & Regards
Vivek
--
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 RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.
Hi Kishon,
On Fri, Feb 1, 2013 at 10:51 AM, kishon wrote:
> Hi,
>
>
> On Thursday 31 January 2013 09:08 PM, Felipe Balbi wrote:
>>
>> On Thu, Jan 31, 2013 at 09:00:37PM +0530, Vivek Gautam wrote:
>>>
>>> Hi Felipe,
>>>
>>>
>>> On Thu, Jan 31, 2013 at 8:55 PM, Felipe Balbi wrote:
Hi,
On Thu, Jan 31, 2013 at 08:53:27PM +0530, Vivek Gautam wrote:
>>>
>>> Moreover, SoCs having multiple dwc3 controllers will have multiple
>>> PHYs, which eventually be added using usb_add_phy_dev(), and not
>>> using usb_add_phy(). So each dwc3 controller won't be able to
>>> get PHYs by simply calling devm_usb_get_phy() also.
>>
>>
>> No. We have added usb_get_phy_dev() for that purpose in the case of
>> non-dt.
>> I think, instead you can have a patch to use devm_usb_get_phy_dev()
>> here and
>> in exynos platform specific code use usb_bind_phy() to bind the phy
>> and
>> controller till you change it to dt.
>>
>
> We have dt support for dwc3-exynos, in such case we should go ahead
> with
> of_platform_populate(), right ?
> But if when i use of_platform_populate() i will not be able to set
> dma_mask to dwc3->dev. :-(
>
>
> You can do something like this
>
> static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
>
> static int dwc3_exynos_set_dmamask(struct device *dev, void *c)
> {
> dev->dma_mask = &dwc3_exynos_dma_mask;
>
> return 0;
> }
>
> And in your probe after of_platform_populate, you can add
>
> device_for_each_child(&pdev->dev, NULL, dwc3_exynos_set_dmamask);
>
> Here pdev is the platform device of dwc3-exynos. By this way all the
> children of dwc3-exynos will have dma_mask set to the required value.
>
Nice idea, thanks :-)
hmm.. so i can patch this now, and get things working ;-)
> I'm not sure if there is any other better way to achieve the same (without
> patching of.c ;-))
>
--
Thanks & Regards
Vivek
--
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] ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node
On Fri, Feb 01, 2013 at 11:07:27, Philip, Avinash wrote: > DT field of "interrupts" was mentioned wrongly as "interrupt" in SPI > node. This went unnoticed as spi-omap2 driver not making use of > interrupt. Fixes the typo. > > Signed-off-by: Philip Avinash Reported-by: Vaibhav Bedia Typo mistake was reported by Vaibhav. I forgot to mention "Reported-by" tag while posting. Add the same on his behalf. Thanks Avinash > --- > arch/arm/boot/dts/am33xx.dtsi |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > index fbcb90b..cece3ad 100644 > --- a/arch/arm/boot/dts/am33xx.dtsi > +++ b/arch/arm/boot/dts/am33xx.dtsi > @@ -309,7 +309,7 @@ > #address-cells = <1>; > #size-cells = <0>; > reg = <0x4803 0x400>; > - interrupt = <65>; > + interrupts = <65>; > ti,spi-num-cs = <2>; > ti,hwmods = "spi0"; > status = "disabled"; > @@ -320,7 +320,7 @@ > #address-cells = <1>; > #size-cells = <0>; > reg = <0x481a 0x400>; > - interrupt = <125>; > + interrupts = <125>; > ti,spi-num-cs = <2>; > ti,hwmods = "spi1"; > 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
Re: [PATCH v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Thu, 2013-01-31 at 16:42 -0500, Matt Porter wrote: > On Thu, Jan 31, 2013 at 08:58:39PM +, Arnd Bergmann wrote: > > On Thursday 31 January 2013, Matt Porter wrote: > > > On Wed, Jan 30, 2013 at 09:32:58AM +, Arnd Bergmann wrote: > > > > On Wednesday 30 January 2013, Matt Porter wrote: > > > > > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); > > > > > + of_dma_controller_register(dev->of_node, > > > > > + of_dma_simple_xlate, > > > > > + &edma_filter_info); > > > > > + } > > > > > > > > How do you actually deal with the problem mentioned by Padma, that > > > > the filter function does not know which edma instance it is looking > > > > at? If you assume that there can only be a single edma instance in > > > > the system, that is probably a limitation that should be documented > > > > somewhere, and ideally the probe() function should check for that. > > > > > > I make an assumption of one edma instance in the system in the case of > > > DT being populated. This is always true right now as the only SoC with > > > two EDMA controllers in existence is Davinci DA850. Until recently, > > > Davinci had no DT support. Given the steady work being done today on DT > > > support for DA850, it'll probably be something needed in 3.10. > > > > > > I will add a comment and check in probe() to capture this assumption > > > and then plan to update separately to support DA850 booting from DT. > > > > Ok, sounds good. Hopefully by then we will already have a nicer > > way to write an xlate function that does not rely on a filter > > function. > > Yes, it would be nice to avoid what Padma had to do. I should have > mentioned also that the second EDMA on DA850 has no DMA events of > immediate use on it anyway. All the in-kernel users use events on the > first controller, except for the second MMC instance. That's only used > for a wl12xx module on the EVM and that driver has no DT support so it > doesn't matter yet in the DT case. Because of this, DA850 can actually > add EDMA DT support immediately (on top of this series) and add DMA > support to the DT support already posted for the Davinci SPI and MMC > client drivers. I haven't followed this whole discussion in details, but please notice that I'm aiming to get DT support for the WiLink modules (wlcore, wl12xx...) for 3.10. ;) -- Cheers, Luca. -- 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] ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node
DT field of "interrupts" was mentioned wrongly as "interrupt" in SPI node. This went unnoticed as spi-omap2 driver not making use of interrupt. Fixes the typo. Signed-off-by: Philip Avinash --- arch/arm/boot/dts/am33xx.dtsi |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index fbcb90b..cece3ad 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -309,7 +309,7 @@ #address-cells = <1>; #size-cells = <0>; reg = <0x4803 0x400>; - interrupt = <65>; + interrupts = <65>; ti,spi-num-cs = <2>; ti,hwmods = "spi0"; status = "disabled"; @@ -320,7 +320,7 @@ #address-cells = <1>; #size-cells = <0>; reg = <0x481a 0x400>; - interrupt = <125>; + interrupts = <125>; ti,spi-num-cs = <2>; ti,hwmods = "spi1"; 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
Re: [PATCH RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.
Hi,
On Thursday 31 January 2013 09:08 PM, Felipe Balbi wrote:
On Thu, Jan 31, 2013 at 09:00:37PM +0530, Vivek Gautam wrote:
Hi Felipe,
On Thu, Jan 31, 2013 at 8:55 PM, Felipe Balbi wrote:
Hi,
On Thu, Jan 31, 2013 at 08:53:27PM +0530, Vivek Gautam wrote:
Moreover, SoCs having multiple dwc3 controllers will have multiple
PHYs, which eventually be added using usb_add_phy_dev(), and not
using usb_add_phy(). So each dwc3 controller won't be able to
get PHYs by simply calling devm_usb_get_phy() also.
No. We have added usb_get_phy_dev() for that purpose in the case of non-dt.
I think, instead you can have a patch to use devm_usb_get_phy_dev() here and
in exynos platform specific code use usb_bind_phy() to bind the phy and
controller till you change it to dt.
We have dt support for dwc3-exynos, in such case we should go ahead with
of_platform_populate(), right ?
But if when i use of_platform_populate() i will not be able to set
dma_mask to dwc3->dev. :-(
You can do something like this
static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
static int dwc3_exynos_set_dmamask(struct device *dev, void *c)
{
dev->dma_mask = &dwc3_exynos_dma_mask;
return 0;
}
And in your probe after of_platform_populate, you can add
device_for_each_child(&pdev->dev, NULL, dwc3_exynos_set_dmamask);
Here pdev is the platform device of dwc3-exynos. By this way all the
children of dwc3-exynos will have dma_mask set to the required value.
I'm not sure if there is any other better way to achieve the same
(without patching of.c ;-))
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock identifiers for OMAP4460 and OMAP4430
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Friday, January 25, 2013 2:21 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; Valentin, Eduardo; mturque...@linaro.org Subject: Re: [PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock identifiers for OMAP4460 and OMAP4430 Hi, On Fri, 18 Jan 2013, J Keerthy wrote: > The previous logic to detect the clocks for OMAP4460 > was to combine the clocks marked as CK_443X and CK_446X. This would be > fine as long as OMAP4460 was a super set of OMAP4430 clock set. > This is not the case as there are clocks which are specific to OMAP4430 > (for example bandgap_fclk) and some which are specific to OMAP4460(for example > bandgap_ts_fclk). > The clock "bandgap_fclk" is specific for OMAP4430 and > this was added as part of OMAP4460 clock set which should not be done. > > Hence changing the convention. > > CK_446X > Clocks specific to OMAP4460 > CK_443X > Clocks specific to OMAP4430 > CK_44XX (CK_446X | CK_443X) > Common to both OMAP4460 and OMAP4430 > > Boot Tested on both Panda and Panda-es. > > Signed-off-by: J Keerthy > Reviewed-by: Rajendra Nayak > Cc: Paul Walmsley > Cc: Eduardo Valentin While I agree with this patch, my understanding is that Tony wishes to shift to list-based initialization for clocks, similar to how the hwmod initialization is done for OMAP3. This will result in moving away from the CK_* flags. There are some previous public mailing list messages on this topic that you can probably find by searching for CK_446X. Now that we've switched to the common clock framework, it should be more practical to do this conversion, since we can refer to parent clocks by name rather than by pointer. Could you please update your patch to take that approach instead? I sent a fresh patch which knocks of all the CK_* flags and creates lists For initialization of clocks similar to the hwmod approach for OMAP3. - Paul Thanks, Keerthy -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Patch v2 2/2] ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check" bug
On Thu, Jan 31, 2013 at 21:00:32, Paul Walmsley wrote:
> + Koen
>
> Hi
>
> On Thu, 31 Jan 2013, Hebbar Gururaja wrote:
>
> > am33xx_cm_wait_module_ready() checks if register offset is NULL.
> >
> > int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
> > {
> > int i = 0;
> >
> > if (!clkctrl_offs)
> > return 0;
> >
> > In case of AM33xx, CLKCTRL register offset for different clock domains
> > are not uniformly placed. An example of this would be the RTC clock
> > domain with CLKCTRL offset at 0x00.
> > In such cases the module ready check is skipped which leads to a data
> > abort during boot-up when RTC registers is accessed.
> >
> > Remove this check here to avoid checking module readiness for modules
> > with clkctrl register offset at 0x00.
> >
> > Signed-off-by: Hebbar Gururaja
>
> Some text has been added to the patch description to describe Koen's test
> results, and the updated patch has been queued for v3.8-rc fixes. Updated
> patch follows.
>
> - Paul
Thanks for the review & update.
Regards,
Gururaja
>
> From: Hebbar Gururaja
> Date: Thu, 31 Jan 2013 19:55:27 +0530
> Subject: [PATCH] ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check"
> bug
>
> am33xx_cm_wait_module_ready() checks if register offset is NULL.
>
> int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
> {
> int i = 0;
>
> if (!clkctrl_offs)
> return 0;
>
> In case of AM33xx, CLKCTRL register offset for different clock domains
> are not uniformly placed. An example of this would be the RTC clock
> domain with CLKCTRL offset at 0x00.
> In such cases the module ready check is skipped which leads to a data
> abort during boot-up when RTC registers is accessed.
>
> Remove this check here to avoid checking module readiness for modules
> with clkctrl register offset at 0x00.
>
> Koen Kooi notes that this patch fixes a crash on boot with
> CONFIG_RTC_DRV_OMAP=y with v3.8-rc5.
>
> Signed-off-by: Hebbar Gururaja
> Cc: Koen Kooi
> [p...@pwsan.com: noted Koen's test in the patch description]
> Signed-off-by: Paul Walmsley
> ---
> arch/arm/mach-omap2/cm33xx.c |3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
> index 058ce3c..325a515 100644
> --- a/arch/arm/mach-omap2/cm33xx.c
> +++ b/arch/arm/mach-omap2/cm33xx.c
> @@ -241,9 +241,6 @@ int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16
> clkctrl_offs)
> {
> int i = 0;
>
> - if (!clkctrl_offs)
> - return 0;
> -
> omap_test_timeout(_is_module_ready(inst, cdoffs, clkctrl_offs),
> MAX_MODULE_READY_TIME, i);
>
> --
> 1.7.10.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Patch v2 1/2] ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST flags
On Thu, Jan 31, 2013 at 20:58:24, Paul Walmsley wrote:
> Hi
>
> On Thu, 31 Jan 2013, Hebbar Gururaja wrote:
>
> > struct omap_hwmod records belonging to wkup m3 domain is missing
> > HWMOD_NO_IDLEST flags; add them.
> >
> > Signed-off-by: Hebbar Gururaja
>
> I've modified this patch to add some more description of why it's needed
> as a fix, and queued it for v3.8-rc fixes.
>
> Updated patch follows.
Thanks for the review & update.
Regards,
Gururaja
>
>
> - Paul
>
> From: Hebbar Gururaja
> Date: Thu, 31 Jan 2013 19:55:26 +0530
> Subject: [PATCH] ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST
> flags
>
> struct omap_hwmod records belonging to wkup m3 domain is missing
> HWMOD_NO_IDLEST flags; add them.
>
> This patch is a prerequisite for a subsequent patch, 'ARM: OMAP2:
> am33xx-hwmod: Fix "register offset NULL check" bug'. That patch would
> otherwise attempt to read from reserved bits.
>
> Signed-off-by: Hebbar Gururaja
> [p...@pwsan.com: add some more explanation in the patch description]
> Signed-off-by: Paul Walmsley
> ---
> arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> index 646c14d..1ab693e 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> @@ -262,7 +262,8 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
> .name = "wkup_m3",
> .class = &am33xx_wkup_m3_hwmod_class,
> .clkdm_name = "l4_wkup_aon_clkdm",
> - .flags = HWMOD_INIT_NO_RESET, /* Keep hardreset asserted */
> + /* Keep hardreset asserted */
> + .flags = HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
> .mpu_irqs = am33xx_wkup_m3_irqs,
> .main_clk = "dpll_core_m4_div2_ck",
> .prcm = {
> --
> 1.7.10.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Existing queued v3.8-rc fixes postponed to v3.9
Hi, so, v3.8-rc6 is out, and based on Linus' release message: http://marc.info/?l=linux-kernel&m=135968304820921&w=2 he only wants to see patches that "fix major security issues, big user-reported regressions, or nasty oopses". So as a result the fixes that you've recently sent will be deferred to the v3.9 merge window. ... As far as the OMAP4 PM stuff goes, I'm pretty disappointed that v3.8 is going to be released with non-obvious bootloader dependencies for full-chip power management. Let's get the warning patch written and posted right away so it can go in during the v3.9 merge window. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drivers: net: cpsw: Add helper functions for VLAN ALE implementation
Mugunthan V N : > On 1/31/2013 3:32 AM, Francois Romieu wrote: [...] > > It could be factored out. > Are you mentioning to have static inline function for the above two > statements above? Yes. The helper function does not need to be inlined if it does not save space: this path is not performance critical. [...] > >Patch #2 doesn't use the returned status code. > Will modify the prototype to return void :o( The driver should notify the upper layers that the request failed instead of hiding the stuff under the carpet. -- Ueimor -- 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/4] drm/i2c: nxp-tda998x (v3)
On Thu, Jan 31, 2013 at 2:14 PM, Sebastian Hesselbarth
wrote:
> On 01/31/2013 03:23 PM, Rob Clark wrote:
>>
>> On Wed, Jan 30, 2013 at 8:23 PM, Sebastian Hesselbarth
>> wrote:
>>>
>>> On 01/29/2013 06:23 PM, Rob Clark wrote:
>
> [...]
+
+/* The TDA9988 series of devices use a paged register scheme.. to
simplify
+ * things we encode the page # in upper bits of the register #. To
read/
+ * write a given register, we need to make sure CURPAGE register is set
+ * appropriately. Which implies reads/writes are not atomic. Fun!
+ */
>>>
>>>
>>> Please have a look at regmap-i2c, it also supports paged i2c registers
>>> and will save you _a lot_ of the i2c handling.
>>
>>
>> Yeah, I have looked at it, and will eventually convert over to using
>> it. The problems at the moment are that I don't really have enough
>> documentation about the chip at the register level to properly use the
>> caching modes, and from my digging through the regmap code it looked
>> like paged regmap + non-caching will result in writes to the page
>> register for every transaction. That, and a bit of docs or few more
>> examples of using the paging support in regmap would be nice. For
>> now, I am punting on regmap conversion.
>
>
> Hmm, flipping through the public tda998x sources *sigh* I found a
> quite complete register list that also states if registers are RO or RW.
> Even if you are not using all registers you can still prevent regmap from
> reading/writing to them. But yes, documentation lacks some examples ;)
>
>
[...]
+
+/* Device versions: */
+#define TDA9989N2 0x0101
+#define TDA19989 0x0201
+#define TDA19989N20x0202
+#define TDA19988 0x0301
>>>
>>>
>>>
>>> Maybe split this into device_version/revision? What does N2 stand for
>>> or is this the name NXP uses for that device?
>>
>>
>> The register names are based on the names used in the NXP out-of-tree
>> driver (the 50kloc monstrosity, if you've seen it).. that was pretty
>> much all the register level documentation I had.
>
>
> Yeah, but there is a comment about N2, that says the last bit is "not a
> register bit, but is derived by the driver from the new N5 registers..".
> I guess you will not see that many i2c devices returning you "N2" version
> registers..
>
hmm, maybe you are looking at a different (newer?) version of the nxp
code? I did not see this. Perhaps the "n2" stuff isn't too critical,
but I figured it would be nice to see if someone is trying to bring up
a device with one of these parts and I ask them to send me a boot log
with drm traces enabled
>
[...]
>>>
>>>
+static void
+cec_write(struct drm_encoder *encoder, uint16_t addr, uint8_t val)
+{
+ struct i2c_client *client = to_tda998x_priv(encoder)->cec;
+ uint8_t buf[] = {addr, val};
+ int ret;
+
+ ret = i2c_master_send(client, buf, ARRAY_SIZE(buf));
+ if (ret< 0)
+ dev_err(&client->dev, "Error %d writing to cec:0x%x\n",
ret, addr);
+}
>>>
>>>
>>>
>>> Has there been any decision on how to split/integrate cec from drm?
>>> Or is there display stuff located in cec i2c slave (I see HPD in
>>> ..._detect below)?
>>
>>
>> not sure, but at least in this case it can't really be decoupled. I
>> need to use the CEC interface for HPD (as you noticed) and also to
>> power up the HDMI bits..
>
>
> Just to make things clearer here, TDA998x ususally has two i2c slaves
> at power-up, 0x70 (hdmi slave) and 0x34 (cec slave). Are you actually
> accessing the cec slave?
yes, as I mentioned, it is not possible to access the hdmi slave
without first accessing the cec slave to enable the hdmi slave
> [...]
>
+static bool
+tda998x_encoder_mode_fixup(struct drm_encoder *encoder,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ return true;
+}
+
+static int
+tda998x_encoder_mode_valid(struct drm_encoder *encoder,
+ struct drm_display_mode *mode)
+{
+ return MODE_OK;
+}
>>>
>>>
>>>
>>> At least a note would be helpful to see what callbacks are
>>> not yet done. I guess there will be some kind of mode check
>>> someday?
>>
>>
>> Well, some of these drm will assume the fxn ptrs are not null, so we
>> need something even if it is empty.
>>
>> I suppose there are must be some upper bounds on pixel clock
>> supported, which could perhaps be added some day in _mode_valid(). On
>
>
> Depends what drm expects on mode_valid or mode_fixup, I haven't dug into
> drm encoders, yet. But usually for HDMI/DVI you will only choose between
> modes supplied by monitor EDID and not choose something "close". Anyway,
> I just think a note about stuff that is not yet working is helpful.
>
I would put a n
Re: [PATCH v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Thu, Jan 31, 2013 at 08:58:39PM +, Arnd Bergmann wrote: > On Thursday 31 January 2013, Matt Porter wrote: > > On Wed, Jan 30, 2013 at 09:32:58AM +, Arnd Bergmann wrote: > > > On Wednesday 30 January 2013, Matt Porter wrote: > > > > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); > > > > + of_dma_controller_register(dev->of_node, > > > > + of_dma_simple_xlate, > > > > + &edma_filter_info); > > > > + } > > > > > > How do you actually deal with the problem mentioned by Padma, that > > > the filter function does not know which edma instance it is looking > > > at? If you assume that there can only be a single edma instance in > > > the system, that is probably a limitation that should be documented > > > somewhere, and ideally the probe() function should check for that. > > > > I make an assumption of one edma instance in the system in the case of > > DT being populated. This is always true right now as the only SoC with > > two EDMA controllers in existence is Davinci DA850. Until recently, > > Davinci had no DT support. Given the steady work being done today on DT > > support for DA850, it'll probably be something needed in 3.10. > > > > I will add a comment and check in probe() to capture this assumption > > and then plan to update separately to support DA850 booting from DT. > > Ok, sounds good. Hopefully by then we will already have a nicer > way to write an xlate function that does not rely on a filter > function. Yes, it would be nice to avoid what Padma had to do. I should have mentioned also that the second EDMA on DA850 has no DMA events of immediate use on it anyway. All the in-kernel users use events on the first controller, except for the second MMC instance. That's only used for a wl12xx module on the EVM and that driver has no DT support so it doesn't matter yet in the DT case. Because of this, DA850 can actually add EDMA DT support immediately (on top of this series) and add DMA support to the DT support already posted for the Davinci SPI and MMC client drivers. -Matt -- 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 v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Thursday 31 January 2013, Matt Porter wrote: > On Wed, Jan 30, 2013 at 09:32:58AM +, Arnd Bergmann wrote: > > On Wednesday 30 January 2013, Matt Porter wrote: > > > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); > > > + of_dma_controller_register(dev->of_node, > > > + of_dma_simple_xlate, > > > + &edma_filter_info); > > > + } > > > > How do you actually deal with the problem mentioned by Padma, that > > the filter function does not know which edma instance it is looking > > at? If you assume that there can only be a single edma instance in > > the system, that is probably a limitation that should be documented > > somewhere, and ideally the probe() function should check for that. > > I make an assumption of one edma instance in the system in the case of > DT being populated. This is always true right now as the only SoC with > two EDMA controllers in existence is Davinci DA850. Until recently, > Davinci had no DT support. Given the steady work being done today on DT > support for DA850, it'll probably be something needed in 3.10. > > I will add a comment and check in probe() to capture this assumption > and then plan to update separately to support DA850 booting from DT. Ok, sounds good. Hopefully by then we will already have a nicer way to write an xlate function that does not rely on a filter function. Arnd -- 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, RFC] default machine descriptor for multiplatform
On Thursday 31 January 2013, Stephen Warren wrote:
> With that change, we can remove the custom .init_machine() functions for
> all of Tegra, since they just do that:-)
Yes, actually quite a lot of them have the same code, and we also have
an increasing number of users of the irqchip_init and clocksource_of_init,
so those can also be cleaned up as a follow-on to this patch.
The main thing that has to remain for a lot of the platforms is SMP
support, and I don't see a good way around that yet.
> > diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
>
> > +#ifdef CONFIG_IRQCHIP
> > void __init irqchip_init(void)
> > {
> > of_irq_init(__irqchip_begin);
> > }
> > +#else
> > +static inline void irqchip_init(void)
> > +{
> > +}
> > +#endif
>
> That'd need to go in a header file.
Yep, you're right, my mistake.
Arnd
--
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, RFC] default machine descriptor for multiplatform
On Thu, 31 Jan 2013, Arnd Bergmann wrote:
> This is what I think it would look like to do a default platform
> with an empty machine descriptor on ARM. It makes the few required
> entries in the descriptor optional by using the new irqchip_init()
> and clocksource_of_init() functions as defaults, and adds
> a fallback for the DT case to customize_machine to probe all
> the default devices.
>
> For the case that CONFIG_MULTIPLATFORM is enabled, it then
> adds a machine descriptor that never matches any machine but
> is used as a fallback if nothing else matches.
>
> Signed-off-by: Arnd Bergmann
Looks sensible.
Acked-by: Nicolas Pitre
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 3e3444e..8ff1d38 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -979,7 +979,6 @@ config ARCH_MULTI_V7
> bool "ARMv7 based platforms (Cortex-A, PJ4, Krait)"
> default y
> select ARCH_MULTI_V6_V7
> - select ARCH_VEXPRESS
> select CPU_V7
>
> config ARCH_MULTI_V6_V7
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 70f1bde..e6e34ba 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned
> int dt_phys)
> unsigned long dt_root;
> const char *model;
>
> + if (IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
> + DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> + MACHINE_END
> +
> + mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
> + }
> +
> if (!dt_phys)
> return NULL;
>
> @@ -199,7 +206,7 @@ struct machine_desc * __init setup_machine_fdt(unsigned
> int dt_phys)
> mdesc_score = score;
> }
> }
> - if (!mdesc_best) {
> + if (!mdesc_best && !IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
> const char *prop;
> long size;
>
> diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
> index 8e4ef4c..df6f9a1 100644
> --- a/arch/arm/kernel/irq.c
> +++ b/arch/arm/kernel/irq.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -114,7 +115,10 @@ EXPORT_SYMBOL_GPL(set_irq_flags);
>
> void __init init_IRQ(void)
> {
> - machine_desc->init_irq();
> + if (machine_desc->init_irq)
> + machine_desc->init_irq();
> + else
> + irqchip_init();
> }
>
> #ifdef CONFIG_MULTI_IRQ_HANDLER
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 3f6cbb2..1d40c9d 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -640,9 +641,17 @@ struct screen_info screen_info = {
>
> static int __init customize_machine(void)
> {
> - /* customizes platform devices, or adds new ones */
> + /*
> + * customizes platform devices, or adds new ones
> + * On DT based machines, we fall back to populating the
> + * machine from the device tree, if no callback is provided,
> + * otherwise we would always need an init_machine callback.
> + */
> if (machine_desc->init_machine)
> machine_desc->init_machine();
> + else
> + of_platform_populate(NULL, of_default_bus_match_table,
> + NULL, NULL);
> return 0;
> }
> arch_initcall(customize_machine);
> @@ -732,7 +741,7 @@ void __init setup_arch(char **cmdline_p)
>
> setup_processor();
> mdesc = setup_machine_fdt(__atags_pointer);
> - if (!mdesc)
> + if (!mdesc && __machine_arch_type != ~0)
> mdesc = setup_machine_tags(__atags_pointer,
> __machine_arch_type);
> machine_desc = mdesc;
> machine_name = mdesc->name;
> diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
> index 955d92d..abff4e9 100644
> --- a/arch/arm/kernel/time.c
> +++ b/arch/arm/kernel/time.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -115,6 +116,10 @@ int __init register_persistent_clock(clock_access_fn
> read_boot,
>
> void __init time_init(void)
> {
> - machine_desc->init_time();
> + if (machine_desc->init_time)
> + machine_desc->init_time();
> + else
> + clocksource_of_init();
> +
> sched_clock_postinit();
> }
> diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
> index f496afc..c5e7a45 100644
> --- a/drivers/irqchip/irqchip.c
> +++ b/drivers/irqchip/irqchip.c
> @@ -24,7 +24,13 @@ irqchip_of_match_end __used __section(__irqchip_of_end);
>
> extern struct of_device_id __irqchip_begin[];
>
> +#ifdef CONFIG_IRQCHIP
> void __init irqchip_init(void)
> {
> of_irq_init(__irqchip_begin);
> }
> +#else
> +static inline void irqchip_init(void)
> +{
> +}
> +#endif
> diff --
Re: [PATCH 2/4] drm/i2c: nxp-tda998x (v3)
On 01/31/2013 03:23 PM, Rob Clark wrote:
On Wed, Jan 30, 2013 at 8:23 PM, Sebastian Hesselbarth
wrote:
On 01/29/2013 06:23 PM, Rob Clark wrote:
[...]
+
+/* The TDA9988 series of devices use a paged register scheme.. to
simplify
+ * things we encode the page # in upper bits of the register #. To read/
+ * write a given register, we need to make sure CURPAGE register is set
+ * appropriately. Which implies reads/writes are not atomic. Fun!
+ */
Please have a look at regmap-i2c, it also supports paged i2c registers
and will save you _a lot_ of the i2c handling.
Yeah, I have looked at it, and will eventually convert over to using
it. The problems at the moment are that I don't really have enough
documentation about the chip at the register level to properly use the
caching modes, and from my digging through the regmap code it looked
like paged regmap + non-caching will result in writes to the page
register for every transaction. That, and a bit of docs or few more
examples of using the paging support in regmap would be nice. For
now, I am punting on regmap conversion.
Hmm, flipping through the public tda998x sources *sigh* I found a
quite complete register list that also states if registers are RO or RW.
Even if you are not using all registers you can still prevent regmap from
reading/writing to them. But yes, documentation lacks some examples ;)
[...]
+
+/* Device versions: */
+#define TDA9989N2 0x0101
+#define TDA19989 0x0201
+#define TDA19989N20x0202
+#define TDA19988 0x0301
Maybe split this into device_version/revision? What does N2 stand for
or is this the name NXP uses for that device?
The register names are based on the names used in the NXP out-of-tree
driver (the 50kloc monstrosity, if you've seen it).. that was pretty
much all the register level documentation I had.
Yeah, but there is a comment about N2, that says the last bit is "not a
register bit, but is derived by the driver from the new N5 registers..".
I guess you will not see that many i2c devices returning you "N2" version
registers..
[...]
+static void
+cec_write(struct drm_encoder *encoder, uint16_t addr, uint8_t val)
+{
+ struct i2c_client *client = to_tda998x_priv(encoder)->cec;
+ uint8_t buf[] = {addr, val};
+ int ret;
+
+ ret = i2c_master_send(client, buf, ARRAY_SIZE(buf));
+ if (ret< 0)
+ dev_err(&client->dev, "Error %d writing to cec:0x%x\n",
ret, addr);
+}
Has there been any decision on how to split/integrate cec from drm?
Or is there display stuff located in cec i2c slave (I see HPD in
..._detect below)?
not sure, but at least in this case it can't really be decoupled. I
need to use the CEC interface for HPD (as you noticed) and also to
power up the HDMI bits..
Just to make things clearer here, TDA998x ususally has two i2c slaves
at power-up, 0x70 (hdmi slave) and 0x34 (cec slave). Are you actually
accessing the cec slave?
[...]
+static bool
+tda998x_encoder_mode_fixup(struct drm_encoder *encoder,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ return true;
+}
+
+static int
+tda998x_encoder_mode_valid(struct drm_encoder *encoder,
+ struct drm_display_mode *mode)
+{
+ return MODE_OK;
+}
At least a note would be helpful to see what callbacks are
not yet done. I guess there will be some kind of mode check
someday?
Well, some of these drm will assume the fxn ptrs are not null, so we
need something even if it is empty.
I suppose there are must be some upper bounds on pixel clock
supported, which could perhaps be added some day in _mode_valid(). On
Depends what drm expects on mode_valid or mode_fixup, I haven't dug into
drm encoders, yet. But usually for HDMI/DVI you will only choose between
modes supplied by monitor EDID and not choose something "close". Anyway,
I just think a note about stuff that is not yet working is helpful.
the device I am working on, the limiting factor is the crtc (upstream
of the encoder), so I haven't really needed this yet. I expect that
as people start using this on some other devices, we'll come across
some enhancements needed, some places where we need to add some
configuration, etc. I cannot really predict exactly what is needed,
so I prefer just to put the driver out there in some form, and then
add it it as needed. So, I wouldn't really say that these functions
are "TODO", but I also wouldn't say that we won't find some reason to
add some code there at some point.
Or put it in staging?
[...]
+static enum drm_connector_status
+tda998x_encoder_detect(struct drm_encoder *encoder,
+ struct drm_connector *connector)
+{
+ uint8_t val = cec_read(encoder, REG_CEC_RXSHPDLEV);
+ return (val& CEC_RXSHPDLEV_HPD) ? connector_status_connected :
+ connector_status_disconnect
[PATCH 2/2] ARM: OMAP2+: Export SoC information to userspace
In some situations it is useful for userspace to
know some SoC-specific information. For example,
this may be used for deciding what kernel module to
use or how to better configure some settings etc.
This patch exports OMAP SoC information to userspace
using existing in Linux kernel SoC infrastructure.
This information can be read under
/sys/devices/socX directory
Signed-off-by: Ruslan Bilovol
---
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/common.h |8 ++
arch/arm/mach-omap2/id.c | 65 ++
arch/arm/mach-omap2/io.c |1 +
4 files changed, 75 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fe926e0..47da0bd 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -17,6 +17,7 @@ config ARCH_OMAP2PLUS
select PROC_DEVICETREE if PROC_FS
select SPARSE_IRQ
select USE_OF
+ select SOC_BUS
help
Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 948bcaa..2a6f866 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -111,6 +111,14 @@ void ti81xx_init_late(void);
void omap4430_init_late(void);
int omap2_common_pm_late_init(void);
+#ifdef CONFIG_SOC_BUS
+void omap_soc_device_init(void);
+#else
+static inline void omap_soc_device_init(void)
+{
+}
+#endif
+
#if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
void omap2xxx_restart(char mode, const char *cmd);
#else
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 436fcf9..5724ee8 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,11 @@
#include
#include
#include
+#include
+
+#ifdef CONFIG_SOC_BUS
+#include
+#endif
#include
@@ -572,3 +577,63 @@ void __init omap2_set_globals_tap(u32 class, void __iomem
*tap)
else
tap_prod_id = 0x0208;
}
+
+#ifdef CONFIG_SOC_BUS
+
+static const char const *omap_types[] = {
+ [OMAP2_DEVICE_TYPE_TEST]= "TST",
+ [OMAP2_DEVICE_TYPE_EMU] = "EMU",
+ [OMAP2_DEVICE_TYPE_SEC] = "HS",
+ [OMAP2_DEVICE_TYPE_GP] = "GP",
+ [OMAP2_DEVICE_TYPE_BAD] = "BAD",
+};
+
+static const char * __init omap_get_family(void)
+{
+ if (cpu_is_omap24xx())
+ return kasprintf(GFP_KERNEL, "OMAP2");
+ else if (cpu_is_omap34xx())
+ return kasprintf(GFP_KERNEL, "OMAP3");
+ else if (cpu_is_omap44xx())
+ return kasprintf(GFP_KERNEL, "OMAP4");
+ else if (soc_is_omap54xx())
+ return kasprintf(GFP_KERNEL, "OMAP5");
+ else
+ return kasprintf(GFP_KERNEL, "Unknown");
+}
+
+static ssize_t omap_get_type(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%s\n", omap_types[omap_type()]);
+}
+
+static struct device_attribute omap_soc_attr =
+ __ATTR(type, S_IRUGO, omap_get_type, NULL);
+
+void __init omap_soc_device_init(void)
+{
+ struct device *parent;
+ struct soc_device *soc_dev;
+ struct soc_device_attribute *soc_dev_attr;
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return;
+
+ soc_dev_attr->machine = cpu_name;
+ soc_dev_attr->family = omap_get_family();
+ soc_dev_attr->revision = cpu_rev;
+
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR_OR_NULL(soc_dev)) {
+ kfree(soc_dev_attr);
+ return;
+ }
+
+ parent = soc_device_to_device(soc_dev);
+ if (!IS_ERR_OR_NULL(parent))
+ device_create_file(parent, &omap_soc_attr);
+}
+#endif /* CONFIG_SOC_BUS */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2c3fdd6..08003c1 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -602,6 +602,7 @@ void __init omap4430_init_late(void)
omap2_common_pm_late_init();
omap4_pm_init();
omap2_clk_enable_autoidle_all();
+ omap_soc_device_init();
}
#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 1/2] ARM: OMAP2+: SoC name and revision unification
This is a long story where for each new generation of
OMAP we used different approaches for creating
strings for SoCs names and revisions that this patch
fixes. It makes future exporting of this information
to SoC infrastructure easier.
Signed-off-by: Ruslan Bilovol
---
arch/arm/mach-omap2/id.c | 87 ++
1 file changed, 50 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 45cc7ed4..436fcf9 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -31,8 +31,11 @@
#define OMAP4_SILICON_TYPE_STANDARD0x01
#define OMAP4_SILICON_TYPE_PERFORMANCE 0x02
+#define OMAP_SOC_MAX_NAME_LENGTH 16
+
static unsigned int omap_revision;
-static const char *cpu_rev;
+static char cpu_name[OMAP_SOC_MAX_NAME_LENGTH];
+static char cpu_rev[OMAP_SOC_MAX_NAME_LENGTH];
u32 omap_features;
unsigned int omap_rev(void)
@@ -169,9 +172,12 @@ void __init omap2xxx_check_revision(void)
j = i;
}
- pr_info("OMAP%04x", omap_rev() >> 16);
+ sprintf(cpu_name, "OMAP%04x", omap_rev() >> 16);
+ sprintf(cpu_rev, "ES%x", (omap_rev() >> 12) & 0xf);
+
+ pr_info("%s", cpu_name);
if ((omap_rev() >> 8) & 0x0f)
- pr_info("ES%x", (omap_rev() >> 12) & 0xf);
+ pr_info("%s", cpu_rev);
pr_info("\n");
}
@@ -181,8 +187,7 @@ void __init omap2xxx_check_revision(void)
static void __init omap3_cpuinfo(void)
{
- const char *cpu_name;
-
+ const char *omap3_cpu_name;
/*
* OMAP3430 and OMAP3530 are assumed to be same.
*
@@ -191,28 +196,30 @@ static void __init omap3_cpuinfo(void)
* and CPU class bits.
*/
if (cpu_is_omap3630()) {
- cpu_name = "OMAP3630";
+ omap3_cpu_name = "OMAP3630";
} else if (soc_is_am35xx()) {
- cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
+ omap3_cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
} else if (cpu_is_ti816x()) {
- cpu_name = "TI816X";
+ omap3_cpu_name = "TI816X";
} else if (soc_is_am335x()) {
- cpu_name = "AM335X";
+ omap3_cpu_name = "AM335X";
} else if (cpu_is_ti814x()) {
- cpu_name = "TI814X";
+ omap3_cpu_name = "TI814X";
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
- cpu_name = "OMAP3430/3530";
+ omap3_cpu_name = "OMAP3430/3530";
} else if (omap3_has_iva()) {
- cpu_name = "OMAP3525";
+ omap3_cpu_name = "OMAP3525";
} else if (omap3_has_sgx()) {
- cpu_name = "OMAP3515";
+ omap3_cpu_name = "OMAP3515";
} else {
- cpu_name = "OMAP3503";
+ omap3_cpu_name = "OMAP3503";
}
+ sprintf(cpu_name, "%s", omap3_cpu_name);
+
/* Print verbose information */
- pr_info("%s ES%s (", cpu_name, cpu_rev);
+ pr_info("%s %s (", cpu_name, cpu_rev);
OMAP3_SHOW_FEATURE(l2cache);
OMAP3_SHOW_FEATURE(iva);
@@ -291,6 +298,7 @@ void __init ti81xx_check_features(void)
void __init omap3xxx_check_revision(void)
{
+ const char *omap3_cpu_rev;
u32 cpuid, idcode;
u16 hawkeye;
u8 rev;
@@ -303,7 +311,7 @@ void __init omap3xxx_check_revision(void)
cpuid = read_cpuid(CPUID_ID);
if cpuid >> 4) & 0xfff) == 0xc08) && ((cpuid & 0xf) == 0x0)) {
omap_revision = OMAP3430_REV_ES1_0;
- cpu_rev = "1.0";
+ omap3_cpu_rev = "ES1.0";
return;
}
@@ -324,26 +332,26 @@ void __init omap3xxx_check_revision(void)
case 0: /* Take care of early samples */
case 1:
omap_revision = OMAP3430_REV_ES2_0;
- cpu_rev = "2.0";
+ omap3_cpu_rev = "ES2.0";
break;
case 2:
omap_revision = OMAP3430_REV_ES2_1;
- cpu_rev = "2.1";
+ omap3_cpu_rev = "ES2.1";
break;
case 3:
omap_revision = OMAP3430_REV_ES3_0;
- cpu_rev = "3.0";
+ omap3_cpu_rev = "ES3.0";
break;
case 4:
omap_revision = OMAP3430_REV_ES3_1;
- cpu_rev = "3.1";
+ omap3_cpu_rev = "ES3.1";
break;
case 7:
/* FALLTHROUGH */
default:
/* Use the latest known revision as default */
omap_revision = OMAP3430_REV_ES3_1_2;
- cpu_rev =
[PATCH 0/2] ARM: OMAP2+: Export SoC information to userspace using SoC infrastructure
Hi, This patch series is an attempt to export some OMAP SoC information (like name, revision etc.) to userspace. The first patch does some unification of OMAP SoC information representation in current sources. Second patch adds exactly needed changes using exists in Linux kernel SoC infrastructure. Ruslan Bilovol (2): ARM: OMAP2+: SoC name and revision unification ARM: OMAP2+: Export SoC information to userspace arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/common.h |8 +++ arch/arm/mach-omap2/id.c | 152 -- arch/arm/mach-omap2/io.c |1 + 4 files changed, 125 insertions(+), 37 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
[PATCH v3 1/2] drivers: net: cpsw: Add helper functions for VLAN ALE implementation
Add helper functions for VLAN ALE implementations for Add, Delete
Dump VLAN related ALE entries
Signed-off-by: Mugunthan V N
---
drivers/net/ethernet/ti/cpsw.c |8 +--
drivers/net/ethernet/ti/cpsw_ale.c | 105 +++-
drivers/net/ethernet/ti/cpsw_ale.h | 20 ---
3 files changed, 111 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index b35e6a7..a40750e 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -345,7 +345,7 @@ static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
/* program multicast address list into ALE register */
netdev_for_each_mc_addr(ha, ndev) {
cpsw_ale_add_mcast(priv->ale, (u8 *)ha->addr,
- ALE_ALL_PORTS << priv->host_port, 0, 0);
+ ALE_ALL_PORTS << priv->host_port, 0, 0, 0);
}
}
}
@@ -592,7 +592,7 @@ static void cpsw_slave_open(struct cpsw_slave *slave,
struct cpsw_priv *priv)
slave_port = cpsw_get_slave_port(priv, slave->slave_num);
cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
- 1 << slave_port, 0, ALE_MCAST_FWD_2);
+ 1 << slave_port, 0, 0, ALE_MCAST_FWD_2);
slave->phy = phy_connect(priv->ndev, slave->data->phy_id,
&cpsw_adjust_link, slave->data->phy_if);
@@ -624,9 +624,9 @@ static void cpsw_init_host_port(struct cpsw_priv *priv)
cpsw_ale_control_set(priv->ale, priv->host_port,
ALE_PORT_STATE, ALE_PORT_STATE_FORWARD);
- cpsw_ale_add_ucast(priv->ale, priv->mac_addr, priv->host_port, 0);
+ cpsw_ale_add_ucast(priv->ale, priv->mac_addr, priv->host_port, 0, 0);
cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
- 1 << priv->host_port, 0, ALE_MCAST_FWD_2);
+ 1 << priv->host_port, 0, 0, ALE_MCAST_FWD_2);
}
static int cpsw_ndo_open(struct net_device *ndev)
diff --git a/drivers/net/ethernet/ti/cpsw_ale.c
b/drivers/net/ethernet/ti/cpsw_ale.c
index 0e9ccc2..0354875 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -148,7 +148,7 @@ static int cpsw_ale_write(struct cpsw_ale *ale, int idx,
u32 *ale_entry)
return idx;
}
-static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr)
+int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS];
int type, idx;
@@ -160,6 +160,8 @@ static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8
*addr)
type = cpsw_ale_get_entry_type(ale_entry);
if (type != ALE_TYPE_ADDR && type != ALE_TYPE_VLAN_ADDR)
continue;
+ if (cpsw_ale_get_vlan_id(ale_entry) != vid)
+ continue;
cpsw_ale_get_addr(ale_entry, entry_addr);
if (memcmp(entry_addr, addr, 6) == 0)
return idx;
@@ -167,6 +169,22 @@ static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8
*addr)
return -ENOENT;
}
+int cpsw_ale_match_vlan(struct cpsw_ale *ale, u16 vid)
+{
+ u32 ale_entry[ALE_ENTRY_WORDS];
+ int type, idx;
+
+ for (idx = 0; idx < ale->params.ale_entries; idx++) {
+ cpsw_ale_read(ale, idx, ale_entry);
+ type = cpsw_ale_get_entry_type(ale_entry);
+ if (type != ALE_TYPE_VLAN)
+ continue;
+ if (cpsw_ale_get_vlan_id(ale_entry) == vid)
+ return idx;
+ }
+ return -ENOENT;
+}
+
static int cpsw_ale_match_free(struct cpsw_ale *ale)
{
u32 ale_entry[ALE_ENTRY_WORDS];
@@ -274,19 +292,32 @@ int cpsw_ale_flush(struct cpsw_ale *ale, int port_mask)
return 0;
}
-int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port, int flags)
+static inline void cpsw_ale_set_vlan_entry_type(u32 *ale_entry,
+ int flags, u16 vid)
+{
+ if (flags & ALE_VLAN) {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_VLAN_ADDR);
+ cpsw_ale_set_vlan_id(ale_entry, vid);
+ } else {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
+ }
+}
+
+int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port,
+ int flags, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
int idx;
- cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
+ cpsw_ale_set_vlan_entry_type(ale_entry, flags, vid);
+
cpsw_ale_set_addr(ale_entry, addr);
cpsw_ale_set_ucast_type(ale_entry, ALE_UCAST_PERSISTANT);
cpsw_ale_set_secure(ale_entry, (flags & ALE_SECURE) ? 1 : 0);
cpsw_ale_set_blocked(ale_entry, (flags & ALE_BLOCKED) ? 1 : 0);
cpsw_ale_set_port_num(
[PATCH v3 2/2] drivers: net:ethernet: cpsw: add support for VLAN
adding support for VLAN interface for cpsw.
CPSW VLAN Capability
* Can filter VLAN packets in Hardware
Signed-off-by: Mugunthan V N
---
Documentation/devicetree/bindings/net/cpsw.txt |2 +
drivers/net/ethernet/ti/cpsw.c | 85 +++-
drivers/net/ethernet/ti/cpsw_ale.h |4 ++
include/linux/platform_data/cpsw.h |1 +
4 files changed, 90 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..99696bf 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -24,6 +24,8 @@ Required properties:
Optional properties:
- ti,hwmods: Must be "cpgmac0"
- no_bd_ram: Must be 0 or 1
+- default_vlan : Specifies Default VLAN for non tagged packets
+ ALE processing
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index a40750e..63b1563 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
@@ -118,6 +119,9 @@ do {
\
#define TX_PRIORITY_MAPPING0x33221100
#define CPDMA_TX_PRIORITY_MAP 0x76543210
+#define CPSW_VLAN_AWAREBIT(1)
+#define CPSW_ALE_VLAN_AWARE1
+
#define cpsw_enable_irq(priv) \
do {\
u32 i; \
@@ -607,14 +611,40 @@ static void cpsw_slave_open(struct cpsw_slave *slave,
struct cpsw_priv *priv)
}
}
+static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
+{
+ const int vlan = priv->data.default_vlan;
+ const int port = priv->host_port;
+ u32 reg;
+ int i;
+
+ reg = (priv->version == CPSW_VERSION_1) ? CPSW1_PORT_VLAN :
+ CPSW2_PORT_VLAN;
+
+ writel(vlan, &priv->host_port_regs->port_vlan);
+
+ for (i = 0; i < 2; i++)
+ slave_write(priv->slaves + i, vlan, reg);
+
+ cpsw_ale_add_vlan(priv->ale, vlan, ALE_ALL_PORTS << port,
+ ALE_ALL_PORTS << port, ALE_ALL_PORTS << port,
+ (ALE_PORT_1 | ALE_PORT_2) << port);
+}
+
static void cpsw_init_host_port(struct cpsw_priv *priv)
{
+ u32 control_reg;
+
/* soft reset the controller and initialize ale */
soft_reset("cpsw", &priv->regs->soft_reset);
cpsw_ale_start(priv->ale);
/* switch to vlan unaware mode */
- cpsw_ale_control_set(priv->ale, 0, ALE_VLAN_AWARE, 0);
+ cpsw_ale_control_set(priv->ale, priv->host_port, ALE_VLAN_AWARE,
+CPSW_ALE_VLAN_AWARE);
+ control_reg = readl(&priv->regs->control);
+ control_reg |= CPSW_VLAN_AWARE;
+ writel(control_reg, &priv->regs->control);
/* setup host port priority mapping */
__raw_writel(CPDMA_TX_PRIORITY_MAP,
@@ -650,6 +680,9 @@ static int cpsw_ndo_open(struct net_device *ndev)
cpsw_init_host_port(priv);
for_each_slave(priv, cpsw_slave_open, priv);
+ /* Add default VLAN */
+ cpsw_add_default_vlan(priv);
+
/* setup tx dma to fixed prio and zero offset */
cpdma_control_set(priv->dma, CPDMA_TX_PRIO_FIXED, 1);
cpdma_control_set(priv->dma, CPDMA_RX_BUFFER_OFFSET, 0);
@@ -933,6 +966,49 @@ static void cpsw_ndo_poll_controller(struct net_device
*ndev)
}
#endif
+static inline void cpsw_add_vlan_ale_entry(struct cpsw_priv *priv,
+ unsigned short vid)
+{
+ cpsw_ale_add_vlan(priv->ale, vid, ALE_ALL_PORTS << priv->host_port,
+ 0, ALE_ALL_PORTS << priv->host_port,
+ (ALE_PORT_1 | ALE_PORT_2) << priv->host_port);
+ cpsw_ale_add_ucast(priv->ale, priv->mac_addr,
+ priv->host_port, ALE_VLAN, vid);
+ cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
+ ALE_ALL_PORTS << priv->host_port, ALE_VLAN, vid, 0);
+}
+
+static int cpsw_ndo_vlan_rx_add_vid(struct net_device *ndev,
+ unsigned short vid)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+
+ if (vid == priv->data.default_vlan)
+ return 0;
+
+ dev_info(priv->dev, "Adding vlanid %d to vlan filter\n", vid);
+ cpsw_add_vlan_ale_entry(priv, vid);
+
+ return 0;
+}
+
+static int cpsw_ndo_vlan_rx_kill_vid(struct net_device *ndev,
+ unsigned short vid)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+
+ if (vid == priv->data.default_vlan)
+ return 0;
+
+ dev_info(priv->dev, "removing vlanid %d from vlan filter\n", vid);
+ cpsw_ale_del_vlan(priv->ale, vid, 0);
+ cps
[PATCH v3 0/2] Add CPSW VLAN Support
CPSW is capable of filtering VLAN packets in hardware. This patch series implements VLAN support to CPSW driver. This patch series is tested on net-next with AM335x EVM with ping test. Changes from initial version * added vlan support to existing add/delete unicast/multicast apis * Made driver as default VLAN enabled so that drivers need to be recompiled when stack is compiled with VLAN Changes from V2 * Moved repeated code to static inline function * Made vlan add/delete function return type to void as it is not used in the current driver implementation * Modified cpsw_add_default_vlan for better readability * changed BIT(1) port representation to defines Mugunthan V N (2): drivers: net: cpsw: Add helper functions for VLAN ALE implementation drivers: net:ethernet: cpsw: add support for VLAN Documentation/devicetree/bindings/net/cpsw.txt |2 + drivers/net/ethernet/ti/cpsw.c | 93 +++-- drivers/net/ethernet/ti/cpsw_ale.c | 105 +--- drivers/net/ethernet/ti/cpsw_ale.h | 24 -- include/linux/platform_data/cpsw.h |1 + 5 files changed, 201 insertions(+), 24 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
Re: [PATCH, RFC] default machine descriptor for multiplatform
On 01/31/2013 10:51 AM, Arnd Bergmann wrote:
> This is what I think it would look like to do a default platform
> with an empty machine descriptor on ARM. It makes the few required
> entries in the descriptor optional by using the new irqchip_init()
> and clocksource_of_init() functions as defaults, and adds
> a fallback for the DT case to customize_machine to probe all
> the default devices.
>
> For the case that CONFIG_MULTIPLATFORM is enabled, it then
> adds a machine descriptor that never matches any machine but
> is used as a fallback if nothing else matches.
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> static int __init customize_machine(void)
> {
> - /* customizes platform devices, or adds new ones */
> + /*
> + * customizes platform devices, or adds new ones
> + * On DT based machines, we fall back to populating the
> + * machine from the device tree, if no callback is provided,
> + * otherwise we would always need an init_machine callback.
> + */
> if (machine_desc->init_machine)
> machine_desc->init_machine();
> + else
> + of_platform_populate(NULL, of_default_bus_match_table,
> + NULL, NULL);
With that change, we can remove the custom .init_machine() functions for
all of Tegra, since they just do that:-)
> diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
> +#ifdef CONFIG_IRQCHIP
> void __init irqchip_init(void)
> {
> of_irq_init(__irqchip_begin);
> }
> +#else
> +static inline void irqchip_init(void)
> +{
> +}
> +#endif
That'd need to go in a header file.
--
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 v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Wed, Jan 30, 2013 at 09:32:58AM +, Arnd Bergmann wrote: > On Wednesday 30 January 2013, Matt Porter wrote: > > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); > > + of_dma_controller_register(dev->of_node, > > + of_dma_simple_xlate, > > + &edma_filter_info); > > + } > > How do you actually deal with the problem mentioned by Padma, that > the filter function does not know which edma instance it is looking > at? If you assume that there can only be a single edma instance in > the system, that is probably a limitation that should be documented > somewhere, and ideally the probe() function should check for that. I make an assumption of one edma instance in the system in the case of DT being populated. This is always true right now as the only SoC with two EDMA controllers in existence is Davinci DA850. Until recently, Davinci had no DT support. Given the steady work being done today on DT support for DA850, it'll probably be something needed in 3.10. I will add a comment and check in probe() to capture this assumption and then plan to update separately to support DA850 booting from DT. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH, RFC] default machine descriptor for multiplatform
This is what I think it would look like to do a default platform
with an empty machine descriptor on ARM. It makes the few required
entries in the descriptor optional by using the new irqchip_init()
and clocksource_of_init() functions as defaults, and adds
a fallback for the DT case to customize_machine to probe all
the default devices.
For the case that CONFIG_MULTIPLATFORM is enabled, it then
adds a machine descriptor that never matches any machine but
is used as a fallback if nothing else matches.
Signed-off-by: Arnd Bergmann
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3e3444e..8ff1d38 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -979,7 +979,6 @@ config ARCH_MULTI_V7
bool "ARMv7 based platforms (Cortex-A, PJ4, Krait)"
default y
select ARCH_MULTI_V6_V7
- select ARCH_VEXPRESS
select CPU_V7
config ARCH_MULTI_V6_V7
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..e6e34ba 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned
int dt_phys)
unsigned long dt_root;
const char *model;
+ if (IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
+ DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
+ MACHINE_END
+
+ mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
+ }
+
if (!dt_phys)
return NULL;
@@ -199,7 +206,7 @@ struct machine_desc * __init setup_machine_fdt(unsigned int
dt_phys)
mdesc_score = score;
}
}
- if (!mdesc_best) {
+ if (!mdesc_best && !IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
const char *prop;
long size;
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 8e4ef4c..df6f9a1 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -114,7 +115,10 @@ EXPORT_SYMBOL_GPL(set_irq_flags);
void __init init_IRQ(void)
{
- machine_desc->init_irq();
+ if (machine_desc->init_irq)
+ machine_desc->init_irq();
+ else
+ irqchip_init();
}
#ifdef CONFIG_MULTI_IRQ_HANDLER
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..1d40c9d 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -640,9 +641,17 @@ struct screen_info screen_info = {
static int __init customize_machine(void)
{
- /* customizes platform devices, or adds new ones */
+ /*
+* customizes platform devices, or adds new ones
+* On DT based machines, we fall back to populating the
+* machine from the device tree, if no callback is provided,
+* otherwise we would always need an init_machine callback.
+*/
if (machine_desc->init_machine)
machine_desc->init_machine();
+ else
+ of_platform_populate(NULL, of_default_bus_match_table,
+ NULL, NULL);
return 0;
}
arch_initcall(customize_machine);
@@ -732,7 +741,7 @@ void __init setup_arch(char **cmdline_p)
setup_processor();
mdesc = setup_machine_fdt(__atags_pointer);
- if (!mdesc)
+ if (!mdesc && __machine_arch_type != ~0)
mdesc = setup_machine_tags(__atags_pointer,
__machine_arch_type);
machine_desc = mdesc;
machine_name = mdesc->name;
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 955d92d..abff4e9 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -115,6 +116,10 @@ int __init register_persistent_clock(clock_access_fn
read_boot,
void __init time_init(void)
{
- machine_desc->init_time();
+ if (machine_desc->init_time)
+ machine_desc->init_time();
+ else
+ clocksource_of_init();
+
sched_clock_postinit();
}
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index f496afc..c5e7a45 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -24,7 +24,13 @@ irqchip_of_match_end __used __section(__irqchip_of_end);
extern struct of_device_id __irqchip_begin[];
+#ifdef CONFIG_IRQCHIP
void __init irqchip_init(void)
{
of_irq_init(__irqchip_begin);
}
+#else
+static inline void irqchip_init(void)
+{
+}
+#endif
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 7944f14..b14d224 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -339,6 +339,10 @@ extern void clocksource_of_init(void);
static const struct of_device_id __clksrc_of_table_##name \
Re: OMAP4 PM bootloader dependency problems
On Thu, 31 Jan 2013, Paul Walmsley wrote: > On Thu, 31 Jan 2013, Paul Walmsley wrote: > > > Right. I don't have any problem with adding a message to the suspend path > > also. But I'd like to see a boot-time message added even if > > CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention > > idle with dynamic idle. In other words, not everyone might use 'echo mem > > > /sys/power/state'. > > (and re-reading my original E-mail to Rajendra, I can see that it was > nuclear, so I'm sorry about that.) Hehe, _unclear_. Time to go back to bed... - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 PM bootloader dependency problems
On Thu, 31 Jan 2013, Paul Walmsley wrote: > Right. I don't have any problem with adding a message to the suspend path > also. But I'd like to see a boot-time message added even if > CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention > idle with dynamic idle. In other words, not everyone might use 'echo mem > > /sys/power/state'. (and re-reading my original E-mail to Rajendra, I can see that it was nuclear, so I'm sorry about that.) - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] drm/i2c: nxp-tda998x (v3)
On Thu, Jan 31, 2013 at 08:23:53AM -0600, Rob Clark wrote: > On Wed, Jan 30, 2013 at 8:23 PM, Sebastian Hesselbarth > wrote: > > On 01/29/2013 06:23 PM, Rob Clark wrote: > >> > >> Driver for the NXP TDA998X i2c hdmi encoder slave. > > > > > > Rob, > > > > good to see a driver for TDA998x comming! I'd love to test > > it on CuBox (mach-dove) but there is no gpu driver I can hook up, > > yet. Anyway, I will make some comments how I think the driver > > should be improved. I will eventually pick this up and give it a whirl with my cubox DRM stuff. I've yet to receive my round tuit. -- 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: OMAP4 PM bootloader dependency problems
Hi, On Thu, 31 Jan 2013, Santosh Shilimkar wrote: > On Thursday 31 January 2013 09:10 PM, Paul Walmsley wrote: > > On Thu, 31 Jan 2013, Rajendra Nayak wrote: > > > > > Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note > > > that it isn't enabled by default in omap2plus_defconfig. Also > > > throw one when a suspend fails, saying bootloader *could be* a possible > > > cause specifying the right version to be used. > > > > In my view, these steps aren't sufficient, for the reasons described in > > > > http://marc.info/?l=linux-omap&m=135964568904053&w=2 > > > > Even with CONFIG_CPU_IDLE=n, it's still possible to attempt to enter > > full-chip retention idle on OMAP4 via 'echo mem > /sys/power/state', so it > > doesn't seem right to restrict a solution to that case. > > > > I think rajendra also mentioned adding one in suspend path too > when it fails. > " Also throw one when a suspend fails, saying bootloader > *could be* a possible cause specifying the right version to be used." > > I find Rajendra's suggestion reasonable because some one might > just miss the boot message but getting the message on failure > case cant' be missed. Right. I don't have any problem with adding a message to the suspend path also. But I'd like to see a boot-time message added even if CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention idle with dynamic idle. In other words, not everyone might use 'echo mem > /sys/power/state'. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: AM33XX: clock: SET_RATE_PARENT in lcd path
On Thu, 31 Jan 2013, Paul Walmsley wrote: > This one doesn't apply for me on v3.8-rc5 + your patches 2 and 3. Could > you please update it and re-send? Oops, looks like I accidentally tried to apply the first version of this patch rather than the second one. The second one applies cleanly, so it's queued now for 3.9. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 PM bootloader dependency problems
On Thursday 31 January 2013 09:10 PM, Paul Walmsley wrote: Hi, On Thu, 31 Jan 2013, Rajendra Nayak wrote: Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note that it isn't enabled by default in omap2plus_defconfig. Also throw one when a suspend fails, saying bootloader *could be* a possible cause specifying the right version to be used. In my view, these steps aren't sufficient, for the reasons described in http://marc.info/?l=linux-omap&m=135964568904053&w=2 Even with CONFIG_CPU_IDLE=n, it's still possible to attempt to enter full-chip retention idle on OMAP4 via 'echo mem > /sys/power/state', so it doesn't seem right to restrict a solution to that case. I think rajendra also mentioned adding one in suspend path too when it fails. " Also throw one when a suspend fails, saying bootloader *could be* a possible cause specifying the right version to be used." I find Rajendra's suggestion reasonable because some one might just miss the boot message but getting the message on failure case cant' be missed. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot...
On Thursday 31 January 2013 16:18:23 Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 02:01:14PM -0200, Fabio Estevam wrote: > > On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux > > wrote: > > > > > too. It also looks like Versatile Express support _can't_ be disabled in > > > a multiplatform kernel, which is ludicrous. > > > > Should we go with this approach? > > https://patchwork.kernel.org/patch/1774521/ > > We need to go with an approach which isn't going to break allnoconfig > and randconfig. > > I've suggested that we should have a basic, minimalist platform always > built in for DT supporting kernels. I've actually suggested that we > should end up not having a machine_desc at all once the DT conversion > is complete. Either of those solves the problem of us ending up with > no platform support built with these configurations. Yes, I like the idea a lot. I think we should be pretty close to being able to do that just now, with generic hooks to initialize the interrupt controller and clocksouroce drivers. > The alternative is we end up with quite a long disgusting Kconfig > option which becomes enabled when everything but Versatile Express > is disabled... Yes, I've tried that in the past, it wasn't nice. It also gets much more complex if you want to do it for all configurations instead of just those that enable ARMv7. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: AM33XX: clock: SET_RATE_PARENT in lcd path
On Tue, 22 Jan 2013, Afzal Mohammed wrote: > LCDC clock node is a one that does not have set rate capability. It > just passes on the rate that is sent downstream by it's parent. While > lcdc clock parent and it's grand parent - dpll_disp_m2_ck and > dpll_disp_ck has the capability to configure rate. > > And the default rates provided by LCDC clock's ancestors are not > sufficient to obtain pixel clock for current LCDC use cases, hence > currently display would not work on AM335x SoC's (with driver > modifications in platfrom independent way). > > Hence inform clock framework to propogate set rate for LCDC clock as > well as it's parent - dpll_disp_m2_ck. With this change, set rate on > LCDC clock would get propogated till dpll_disp_ck via dpll_disp_m2_ck, > hence allowing the driver (same driver is used in DaVinci too) to set > rates using LCDC clock without worrying about platform dependent clock > details. > > Signed-off-by: Afzal Mohammed This one doesn't apply for me on v3.8-rc5 + your patches 2 and 3. Could you please update it and re-send? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: OMAP2+: clock: DEFINE_STRUCT_CLK_FLAGS helper
On Tue, 22 Jan 2013, Afzal Mohammed wrote: > DEFINE_STRUCT_CLK does not have the capability to set flags, define > DEFINE_STRUCT_CLK_FLAGS to handle flags. This is needed to add > SET_RATE_PARENT flag in statically defined lcd clock in am335x. > > Signed-off-by: Afzal Mohammed Thanks, queued for 3.9. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot...
On Thu, Jan 31, 2013 at 08:00:02AM -0800, Tony Lindgren wrote: > * Santosh Shilimkar [130131 06:45]: > > On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: > > >>> > > >>># 13 Jan 2013: Update for OMAP moving to multiplatform > > >>>CONFIG_ARCH_MULTIPLATFORM=y > > >>>CONFIG_ARCH_MULTI_V7=y > > >>> > > >>>don't fix it either, it needs more options defined... > > Just trying to figure out what was the missing entry in case > others have the same problem. > > In addition to the ones above, I had also CONFIG_ARCH_OMAP2PLUS=y > listed in my comments. Did you also need something else added > manually? Interesting, that's the one which got missed. The ones which did get updated on the 13th were just the noconfigs which were failing to build, and not the two oldconfigs which are the booted ones. The noconfigs already had OMAP2PLUS enabled in them which is probably how it got lost. -- 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] ARM: omap4: clock data: Add missing clkdm association for dpll_usb
On Thu, 31 Jan 2013, Rajendra Nayak wrote: > Hi Paul, > > > > dpll_usb needs the clkdm association so the clkdm can be > > > turned on before a relock. All other dplls for omap4 belong > > > to the ALWON (always on) domain. > > > > > > The association was present as part of the older data file > > > (clock44xx_data.c) but looks like was accidently dropped with > > > the common clk convertion. > > > > Thanks, queued for v3.8-rc fixes. > > I just realized that apart from adding the missing .clkdm_name, I > also need to populate a .init as part of clk_ops for dpll_usb > so the clockdomain lookup can then happen based on the .clkdm_name. > > I have updated the $Subject patch and posted a v2 (http://marc.info > /?l=linux-omap&m=135963212530790&w=2). Would it be possible for you to > pick the v2 instead and drop this one from your fixes branch. No problem. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: omap4: clock data: Add missing clkdm association for dpll_usb
On Thu, 31 Jan 2013, Rajendra Nayak wrote: > dpll_usb needs the clkdm association so the clkdm can be > turned on before a relock. All other dplls for omap4 belong > to the ALWON (always on) domain. > > The association was present as part of the older data file > (clock44xx_data.c) but looks like got accidently dropped with > the common clk convertion. > > More details of the patch which fixed this up in the older > data file can be dound here.. > http://www.spinics.net/lists/linux-omap/msg63076.html > > Adding the .clkdm_name as part of the clk_hw_omap struct also > means a new .init needs to be part of the clk_ops for dpll_usb > to initialise the clkdm. > > Signed-off-by: Rajendra Nayak Thanks, queued for v3.8-rc in place of v1. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot...
On Thu, Jan 31, 2013 at 02:01:14PM -0200, Fabio Estevam wrote: > On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux > wrote: > > > too. It also looks like Versatile Express support _can't_ be disabled in > > a multiplatform kernel, which is ludicrous. > > Should we go with this approach? > https://patchwork.kernel.org/patch/1774521/ We need to go with an approach which isn't going to break allnoconfig and randconfig. I've suggested that we should have a basic, minimalist platform always built in for DT supporting kernels. I've actually suggested that we should end up not having a machine_desc at all once the DT conversion is complete. Either of those solves the problem of us ending up with no platform support built with these configurations. The alternative is we end up with quite a long disgusting Kconfig option which becomes enabled when everything but Versatile Express is disabled... -- 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 5/5] ARM: OMAP3: Update clocksource timer selection
On 01/31/2013 03:08 AM, Igor Grinberg wrote: > On 01/30/13 19:04, Jon Hunter wrote: >> When booting with device-tree for OMAP3 and AM335x devices and a gptimer >> is used as the clocksource (which is always the case for AM335x), a >> gptimer located in a power domain that is not always-on is selected. >> Ideally we should use a gptimer located in a power domain that is always >> on (such as the wake-up domain) so that time can be maintained during a >> kernel suspend without keeping on additional power domains unnecessarily. >> >> In order to fix this so that we can select a gptimer located in a power >> domain that is always-on, the following changes were made ... >> 1. Currently, only when selecting a gptimer to use for a clockevent >>timer, do we pass a timer property that can be used to select a >>specific gptimer. Change this so that we can pass a property when >>selecting a gptimer to use for a clocksource timer too. >> 2. Currently, when selecting either a gptimer to use for a clockevent >>timer or a clocksource timer and no timer property is passed, then >>the first available timer is selected regardless of the properties >>it has. Change this so that if no properties are passed, then a timer >>that does not have additional features (such as always-on, dsp-irq, >>pwm, and secure) is selected. >> >> Please note that using a gptimer for both clocksource and clockevents >> can have a system power impact during idle. The reason being is that >> OMAP and AMxxx devices typically only have one gptimer in a power domain >> that is always-on. Therefore when the kernel is idle both the clocksource >> and clockevent timers will be active and this will keep additional power >> domains on. During kernel suspend, only the clocksource timer is active >> and therefore, it is better to use a gptimer in a power domain that is >> always-on for clocksource. > > This should explain the gptimer number switch in the > #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) > section below, right? > I would really like to see that clearly stated in the commit message. > For instance: > ... it is better to use a gptimer in a power domain that is > always-on for clocksource. Therefore we switch to use the first gptimer > for clocksource and the second for clockevents. Yes exactly. Good point I can make that bit explicit. >> >> Signed-off-by: Jon Hunter > > Apart from above, > Acked-by: Igor Grinberg Thanks 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: Failure to boot...
On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux wrote: > too. It also looks like Versatile Express support _can't_ be disabled in > a multiplatform kernel, which is ludicrous. Should we go with this approach? https://patchwork.kernel.org/patch/1774521/ -- 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: Failure to boot...
* Santosh Shilimkar [130131 06:45]: > On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: > >>> > >>># 13 Jan 2013: Update for OMAP moving to multiplatform > >>>CONFIG_ARCH_MULTIPLATFORM=y > >>>CONFIG_ARCH_MULTI_V7=y > >>> > >>>don't fix it either, it needs more options defined... Just trying to figure out what was the missing entry in case others have the same problem. In addition to the ones above, I had also CONFIG_ARCH_OMAP2PLUS=y listed in my comments. Did you also need something else added manually? 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: OMAP4 PM bootloader dependency problems
Hi, On Thu, 31 Jan 2013, Rajendra Nayak wrote: > Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note > that it isn't enabled by default in omap2plus_defconfig. Also > throw one when a suspend fails, saying bootloader *could be* a possible > cause specifying the right version to be used. In my view, these steps aren't sufficient, for the reasons described in http://marc.info/?l=linux-omap&m=135964568904053&w=2 Even with CONFIG_CPU_IDLE=n, it's still possible to attempt to enter full-chip retention idle on OMAP4 via 'echo mem > /sys/power/state', so it doesn't seem right to restrict a solution to that case. regards, - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.
On Thu, Jan 31, 2013 at 09:00:37PM +0530, Vivek Gautam wrote: > Hi Felipe, > > > On Thu, Jan 31, 2013 at 8:55 PM, Felipe Balbi wrote: > > Hi, > > > > On Thu, Jan 31, 2013 at 08:53:27PM +0530, Vivek Gautam wrote: > >> >> Moreover, SoCs having multiple dwc3 controllers will have multiple > >> >> PHYs, which eventually be added using usb_add_phy_dev(), and not > >> >> using usb_add_phy(). So each dwc3 controller won't be able to > >> >> get PHYs by simply calling devm_usb_get_phy() also. > >> > > >> > No. We have added usb_get_phy_dev() for that purpose in the case of > >> > non-dt. > >> > I think, instead you can have a patch to use devm_usb_get_phy_dev() here > >> > and > >> > in exynos platform specific code use usb_bind_phy() to bind the phy and > >> > controller till you change it to dt. > >> > > >> > >> We have dt support for dwc3-exynos, in such case we should go ahead with > >> of_platform_populate(), right ? > >> But if when i use of_platform_populate() i will not be able to set > >> dma_mask to dwc3->dev. :-( > > > > do you have a special need for dma_mask because OF already sets it. > > > If i am not wrong of_platform_device_create_pdata() will set > "dev->dev.coherent_dma_mask = DMA_BIT_MASK(32)" > and not dma_mask. > I fact we had some discussion sometime back when we needed the same > for dwc3-exynos in the thread: > [PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree > > But couldn't get final node on it. > So suggestions here please. :-) hmm.. you're right there. Grant, Rob ? Any hints ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP2+: Get rid of custom OMAP_32K_TIMER_HZ
On Thursday 31 January 2013 21:02:00 Santosh Shilimkar wrote: > The timekeeping doesn't depend on HZ value in presence of fine grained > clocksource and hence there should not be any time drift because of HZ > value which was chosen to be divisor of 32768. > > OMAP has been using HZ = 128 value to avoid any time drift issues > because of 32768 HZ clock. But with various measurements performed > with HZ = 100, no time drift is observed and it also proves the > point about HZ not having impact on time keeping on OMAP. > > Very informative thread on this topic is here: > https://lkml.org/lkml/2013/1/29/435 > > Special thanks to John Stulz, Arnd Bergmann and Russell King for their > valuable suggestions. > > Cc: Arnd Bergmann > Cc: Russell King > Cc: John Stultz > Cc: Tony Lindgren Acked-by: Arnd Bergmann Thanks so much for looking into this! -- 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] ARM: OMAP2+: Get rid of custom OMAP_32K_TIMER_HZ
The timekeeping doesn't depend on HZ value in presence of fine grained clocksource and hence there should not be any time drift because of HZ value which was chosen to be divisor of 32768. OMAP has been using HZ = 128 value to avoid any time drift issues because of 32768 HZ clock. But with various measurements performed with HZ = 100, no time drift is observed and it also proves the point about HZ not having impact on time keeping on OMAP. Very informative thread on this topic is here: https://lkml.org/lkml/2013/1/29/435 Special thanks to John Stulz, Arnd Bergmann and Russell King for their valuable suggestions. Cc: Arnd Bergmann Cc: Russell King Cc: John Stultz Cc: Tony Lindgren Signed-off-by: Santosh Shilimkar Tested-by: Lokesh Vutla --- arch/arm/Kconfig|1 - arch/arm/plat-omap/Kconfig |9 - arch/arm/plat-omap/include/plat/timex.h |8 3 files changed, 18 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b35b27f..5493164 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1648,7 +1648,6 @@ config HZ int default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \ ARCH_S5PV210 || ARCH_EXYNOS4 - default OMAP_32K_TIMER_HZ if ARCH_OMAP && OMAP_32K_TIMER default AT91_TIMER_HZ if ARCH_AT91 default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE default 100 diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 67c859c..ce66eb9 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -147,15 +147,6 @@ config OMAP3_L2_AUX_SECURE_SERVICE_SET_ID help PPA routine service ID for setting L2 auxiliary control register. -config OMAP_32K_TIMER_HZ - int "Kernel internal timer frequency for 32KHz timer" - range 32 1024 - depends on OMAP_32K_TIMER - default "128" - help - Kernel internal timer frequency should be a divisor of 32768, - such as 64 or 128. - config OMAP_DM_TIMER bool "Use dual-mode timer" depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS diff --git a/arch/arm/plat-omap/include/plat/timex.h b/arch/arm/plat-omap/include/plat/timex.h index 6d35767..e27d2da 100644 --- a/arch/arm/plat-omap/include/plat/timex.h +++ b/arch/arm/plat-omap/include/plat/timex.h @@ -28,14 +28,6 @@ #if !defined(__ASM_ARCH_OMAP_TIMEX_H) #define __ASM_ARCH_OMAP_TIMEX_H -/* - * OMAP 32KHz timer updates time one jiffie at a time from a secondary timer, - * and that's why the CLOCK_TICK_RATE is not 32768. - */ -#ifdef CONFIG_OMAP_32K_TIMER -#define CLOCK_TICK_RATE(CONFIG_OMAP_32K_TIMER_HZ) -#else #define CLOCK_TICK_RATE(HZ * 10UL) -#endif #endif /* __ASM_ARCH_OMAP_TIMEX_H */ -- 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 RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.
Hi Felipe, On Thu, Jan 31, 2013 at 8:55 PM, Felipe Balbi wrote: > Hi, > > On Thu, Jan 31, 2013 at 08:53:27PM +0530, Vivek Gautam wrote: >> >> Moreover, SoCs having multiple dwc3 controllers will have multiple >> >> PHYs, which eventually be added using usb_add_phy_dev(), and not >> >> using usb_add_phy(). So each dwc3 controller won't be able to >> >> get PHYs by simply calling devm_usb_get_phy() also. >> > >> > No. We have added usb_get_phy_dev() for that purpose in the case of non-dt. >> > I think, instead you can have a patch to use devm_usb_get_phy_dev() here >> > and >> > in exynos platform specific code use usb_bind_phy() to bind the phy and >> > controller till you change it to dt. >> > >> >> We have dt support for dwc3-exynos, in such case we should go ahead with >> of_platform_populate(), right ? >> But if when i use of_platform_populate() i will not be able to set >> dma_mask to dwc3->dev. :-( > > do you have a special need for dma_mask because OF already sets it. > If i am not wrong of_platform_device_create_pdata() will set "dev->dev.coherent_dma_mask = DMA_BIT_MASK(32)" and not dma_mask. I fact we had some discussion sometime back when we needed the same for dwc3-exynos in the thread: [PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree But couldn't get final node on it. So suggestions here please. :-) -- Thanks & Regards Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2 2/2] ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check" bug
+ Koen
Hi
On Thu, 31 Jan 2013, Hebbar Gururaja wrote:
> am33xx_cm_wait_module_ready() checks if register offset is NULL.
>
> int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
> {
> int i = 0;
>
> if (!clkctrl_offs)
> return 0;
>
> In case of AM33xx, CLKCTRL register offset for different clock domains
> are not uniformly placed. An example of this would be the RTC clock
> domain with CLKCTRL offset at 0x00.
> In such cases the module ready check is skipped which leads to a data
> abort during boot-up when RTC registers is accessed.
>
> Remove this check here to avoid checking module readiness for modules
> with clkctrl register offset at 0x00.
>
> Signed-off-by: Hebbar Gururaja
Some text has been added to the patch description to describe Koen's test
results, and the updated patch has been queued for v3.8-rc fixes. Updated
patch follows.
- Paul
From: Hebbar Gururaja
Date: Thu, 31 Jan 2013 19:55:27 +0530
Subject: [PATCH] ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check"
bug
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Koen Kooi notes that this patch fixes a crash on boot with
CONFIG_RTC_DRV_OMAP=y with v3.8-rc5.
Signed-off-by: Hebbar Gururaja
Cc: Koen Kooi
[p...@pwsan.com: noted Koen's test in the patch description]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/cm33xx.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 058ce3c..325a515 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -241,9 +241,6 @@ int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16
clkctrl_offs)
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2 1/2] ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST flags
Hi
On Thu, 31 Jan 2013, Hebbar Gururaja wrote:
> struct omap_hwmod records belonging to wkup m3 domain is missing
> HWMOD_NO_IDLEST flags; add them.
>
> Signed-off-by: Hebbar Gururaja
I've modified this patch to add some more description of why it's needed
as a fix, and queued it for v3.8-rc fixes.
Updated patch follows.
- Paul
From: Hebbar Gururaja
Date: Thu, 31 Jan 2013 19:55:26 +0530
Subject: [PATCH] ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST
flags
struct omap_hwmod records belonging to wkup m3 domain is missing
HWMOD_NO_IDLEST flags; add them.
This patch is a prerequisite for a subsequent patch, 'ARM: OMAP2:
am33xx-hwmod: Fix "register offset NULL check" bug'. That patch would
otherwise attempt to read from reserved bits.
Signed-off-by: Hebbar Gururaja
[p...@pwsan.com: add some more explanation in the patch description]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 646c14d..1ab693e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -262,7 +262,8 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.name = "wkup_m3",
.class = &am33xx_wkup_m3_hwmod_class,
.clkdm_name = "l4_wkup_aon_clkdm",
- .flags = HWMOD_INIT_NO_RESET, /* Keep hardreset asserted */
+ /* Keep hardreset asserted */
+ .flags = HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
.mpu_irqs = am33xx_wkup_m3_irqs,
.main_clk = "dpll_core_m4_div2_ck",
.prcm = {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.
Hi, On Thu, Jan 31, 2013 at 08:53:27PM +0530, Vivek Gautam wrote: > >> Moreover, SoCs having multiple dwc3 controllers will have multiple > >> PHYs, which eventually be added using usb_add_phy_dev(), and not > >> using usb_add_phy(). So each dwc3 controller won't be able to > >> get PHYs by simply calling devm_usb_get_phy() also. > > > > No. We have added usb_get_phy_dev() for that purpose in the case of non-dt. > > I think, instead you can have a patch to use devm_usb_get_phy_dev() here and > > in exynos platform specific code use usb_bind_phy() to bind the phy and > > controller till you change it to dt. > > > > We have dt support for dwc3-exynos, in such case we should go ahead with > of_platform_populate(), right ? > But if when i use of_platform_populate() i will not be able to set > dma_mask to dwc3->dev. :-( do you have a special need for dma_mask because OF already sets it. -- balbi signature.asc Description: Digital signature
Re: [PATCH RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.
Hi Kishon, On Thu, Jan 31, 2013 at 5:04 PM, kishon wrote: > Hi, > Thanks for your quick help. > > On Thursday 31 January 2013 04:50 PM, Vivek Gautam wrote: >> >> With device tree support in place for dwc3-core layer, >> it gets PHY from "synopsis-dwc3" node. >> Some controllers may not have separate memory maps and interrupts >> for dwc3 core and platform glue layers. In such case only glue >> layer's node will exist. > > > Not really. As long as you have dwc3 core as a separate device, you can add > a node for it. > Just that the glue should create a device for dwc3 core using > of_platform_populate.(You can have a look at drivers/usb/dwc3/dwc3-omap.c in > usb-next) > Right, we should be doing this way. >> Moreover, SoCs having multiple dwc3 controllers will have multiple >> PHYs, which eventually be added using usb_add_phy_dev(), and not >> using usb_add_phy(). So each dwc3 controller won't be able to >> get PHYs by simply calling devm_usb_get_phy() also. > > No. We have added usb_get_phy_dev() for that purpose in the case of non-dt. > I think, instead you can have a patch to use devm_usb_get_phy_dev() here and > in exynos platform specific code use usb_bind_phy() to bind the phy and > controller till you change it to dt. > We have dt support for dwc3-exynos, in such case we should go ahead with of_platform_populate(), right ? But if when i use of_platform_populate() i will not be able to set dma_mask to dwc3->dev. :-( And setting it in dwc3_probe() won't be good idea, isn't it ? >> In such cases, dwc3 should expect PHYs from its parent's node. > > NAK. > > Thanks > Kishon > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks & Regards Vivek -- 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: OMAP4 PM bootloader dependency problems
Hi, On Thu, 31 Jan 2013, Tero Kristo wrote: > Personally I don't like too much to have just extra spam during boot, > which in many cases is even unnecessary (e.g. people who actually have > good u-boot in use.) The impact of two or three informative lines sent to the kernel console on boot is lower than the cost of people spending hours trying to figure out why chip retention idle doesn't work. Linux distributions that control the bootloader version can easily comment out the warning. I'm hoping the console messages will inspire someone out there to fix the root cause of the problem -- that the kernel is missing device reset and initialization code for several OMAP4 devices. > Personally I would like to have some sort of test during boot which > detects broken PM and maybe prevents core idle completely if this is the > case. As far as I know, a simple, clean test for this that can be merged right now doesn't exist, and has never been posted to the lists. Personally, it's unclear how such a test can be implemented reliably. You've proposed checking IP block idle/standby states during PM init in previous E-mails. But the problem with this is that those IP blocks might already be in use by their drivers by the time the OMAP4 PM code initializes. It's also important to keep in mind that adding any significant amount of new code this late in the 3.8-rc cycle is not acceptable for my upstreams. That said, if you have a clean, reliable, and short solution for this, please post it by the end of the week. > Alternatively we can add extra info to the failed suspend dump and > mention a good u-boot to try out (v2012-07 or newer.) Folks might be using dynamic idle, so just adding a message on resume from suspend isn't enough. > If we could detect boot loader version from kernel side, that would work > also. I haven't seen any proposals for how to do this. Even if one were available, it would require maintaining kernel blacklists. Considering that the fault is in the kernel OMAP4 integration code and data, adding such a blacklist seems like the wrong approach. ... In any case, all of the options that you've mentioned are workarounds, not real solutions. Fixing the root cause would involve adding reset and initialization code for the remaining devices. No one is working on this as far as I'm aware. And even if they were, it would be too much code to add during the v3.8-rc fixes cycle. I understand that you don't want to add an unconditional message on boot. But right now, it's the best approach. Please post a patch for this by the end of this week that I or Kevin can send upstream ASAP. regards, - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot...
On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: On Thu, Jan 31, 2013 at 07:50:15PM +0530, Santosh Shilimkar wrote: On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: On Thu, Jan 31, 2013 at 02:13:20PM +, Russell King - ARM Linux wrote: On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP. Now trying to merge your for-next and test. Well, my tip (which is based on Linus' 6abb7c25) also builds and boots fine. Hang on... # CONFIG_ARCH_OMAP2PLUS is not set CONFIG_ARCH_VEXPRESS=y which of course won't boot, and this happens on both oldconfigs because of the change to multiplatform support. And no, the instructions given last time around to add: # 13 Jan 2013: Update for OMAP moving to multiplatform CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=y don't fix it either, it needs more options defined... Linus' tip + Tony's pull [1] request also makes things work on OMAP. Thanks to all this multiplatform stuff, the autobuilder has been building nothing but Versatile Express kernels for the last 20 days. That totally explains why it won't boot. The only thing I was told is to add the above two config symbols. That is not the complete story. There's also other symbols which need adding too. It also looks like Versatile Express support _can't_ be disabled in a multiplatform kernel, which is ludicrous. And... fixing the config finally results in something that boots on the SDP4430. Great. Thanks for the confirmation. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot...
On Thu, Jan 31, 2013 at 07:50:15PM +0530, Santosh Shilimkar wrote: > On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 02:13:20PM +, Russell King - ARM Linux wrote: >>> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP. Now trying to merge your for-next and test. >>> >>> Well, my tip (which is based on Linus' 6abb7c25) also builds and >>> boots fine. >>> >>> Hang on... >>> >>> # CONFIG_ARCH_OMAP2PLUS is not set >>> CONFIG_ARCH_VEXPRESS=y >>> >>> which of course won't boot, and this happens on both oldconfigs because >>> of the change to multiplatform support. >> >> And no, the instructions given last time around to add: >> >> # 13 Jan 2013: Update for OMAP moving to multiplatform >> CONFIG_ARCH_MULTIPLATFORM=y >> CONFIG_ARCH_MULTI_V7=y >> >> don't fix it either, it needs more options defined... >> > Linus' tip + Tony's pull [1] request also makes things work > on OMAP. Thanks to all this multiplatform stuff, the autobuilder has been building nothing but Versatile Express kernels for the last 20 days. That totally explains why it won't boot. The only thing I was told is to add the above two config symbols. That is not the complete story. There's also other symbols which need adding too. It also looks like Versatile Express support _can't_ be disabled in a multiplatform kernel, which is ludicrous. And... fixing the config finally results in something that boots on the SDP4430. -- 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/2] ARM: OMAP2+: AM33xx: fix hwmod & Clock Control Module
1. Add add missing HWMOD_NO_IDLEST flags 2. Fix "register offset NULL check" bug Changes in v2: - As per Paul's suggestion 1st add HWMOD_NO_IDLEST flag where it is necessary and then correct the clock control register offset check bug. Hebbar Gururaja (2): ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST flags ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check" bug arch/arm/mach-omap2/cm33xx.c |3 --- arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 ++- 2 files changed, 2 insertions(+), 4 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
[Patch v2 2/2] ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check" bug
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Signed-off-by: Hebbar Gururaja
---
Change in v2:
- No change
:100644 100644 058ce3c... 325a515... M arch/arm/mach-omap2/cm33xx.c
arch/arm/mach-omap2/cm33xx.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 058ce3c..325a515 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -241,9 +241,6 @@ int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16
clkctrl_offs)
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
--
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 v2 1/2] ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST flags
struct omap_hwmod records belonging to wkup m3 domain is missing
HWMOD_NO_IDLEST flags; add them.
Signed-off-by: Hebbar Gururaja
---
Change in v2:
- new patch
:100644 100644 646c14d... 1ab693e... M
arch/arm/mach-omap2/omap_hwmod_33xx_data.c
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 646c14d..1ab693e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -262,7 +262,8 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.name = "wkup_m3",
.class = &am33xx_wkup_m3_hwmod_class,
.clkdm_name = "l4_wkup_aon_clkdm",
- .flags = HWMOD_INIT_NO_RESET, /* Keep hardreset asserted */
+ /* Keep hardreset asserted */
+ .flags = HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
.mpu_irqs = am33xx_wkup_m3_irqs,
.main_clk = "dpll_core_m4_div2_ck",
.prcm = {
--
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 2/4] drm/i2c: nxp-tda998x (v3)
On Wed, Jan 30, 2013 at 8:23 PM, Sebastian Hesselbarth
wrote:
> On 01/29/2013 06:23 PM, Rob Clark wrote:
>>
>> Driver for the NXP TDA998X i2c hdmi encoder slave.
>
>
> Rob,
>
> good to see a driver for TDA998x comming! I'd love to test
> it on CuBox (mach-dove) but there is no gpu driver I can hook up,
> yet. Anyway, I will make some comments how I think the driver
> should be improved.
>
>
>> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
>> index 1611836..4d341db 100644
>> --- a/drivers/gpu/drm/i2c/Kconfig
>> +++ b/drivers/gpu/drm/i2c/Kconfig
>> @@ -19,4 +19,10 @@ config DRM_I2C_SIL164
>> when used in pairs) TMDS transmitters, used in some nVidia
>> video cards.
>>
>> +config DRM_I2C_NXP_TDA998X
>> + tristate "NXP Semiconductors TDA998X HDMI encoder"
>> + default m if DRM_TILCDC
>> + help
>> + Support for NXP Semiconductors TDA998X HDMI encoders.
>
>
> Maybe nit-picking but later down you actually support TDA9989,
> TDA19988, and TDA19989. The latter ones don't fit in TDA998x,
> so at least the Kconfig entry should reflect TDA9989/TDA1998x.
yeah, it is a bit weird naming scheme, but I'm just copying NXP in
referring to the whole family as TDA998x
>> [...]
>>
>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
>> b/drivers/gpu/drm/i2c/tda998x_drv.c
>> new file mode 100644
>> index 000..e68b58a
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>> @@ -0,0 +1,906 @@
>> +/*
>> + * Copyright (C) 2012 Texas Instruments
>> + * Author: Rob Clark
>> + *
>> +
>> [...]
>>
>> +
>> +/* The TDA9988 series of devices use a paged register scheme.. to
>> simplify
>> + * things we encode the page # in upper bits of the register #. To read/
>> + * write a given register, we need to make sure CURPAGE register is set
>> + * appropriately. Which implies reads/writes are not atomic. Fun!
>> + */
>
>
> Please have a look at regmap-i2c, it also supports paged i2c registers
> and will save you _a lot_ of the i2c handling.
Yeah, I have looked at it, and will eventually convert over to using
it. The problems at the moment are that I don't really have enough
documentation about the chip at the register level to properly use the
caching modes, and from my digging through the regmap code it looked
like paged regmap + non-caching will result in writes to the page
register for every transaction. That, and a bit of docs or few more
examples of using the paging support in regmap would be nice. For
now, I am punting on regmap conversion.
>> [...]
>>
>> +
>> +/* Device versions: */
>> +#define TDA9989N2 0x0101
>> +#define TDA19989 0x0201
>> +#define TDA19989N20x0202
>> +#define TDA19988 0x0301
>
>
> Maybe split this into device_version/revision? What does N2 stand for
> or is this the name NXP uses for that device?
The register names are based on the names used in the NXP out-of-tree
driver (the 50kloc monstrosity, if you've seen it).. that was pretty
much all the register level documentation I had.
>> [...]
>
>> +static void
>> +cec_write(struct drm_encoder *encoder, uint16_t addr, uint8_t val)
>> +{
>> + struct i2c_client *client = to_tda998x_priv(encoder)->cec;
>> + uint8_t buf[] = {addr, val};
>> + int ret;
>> +
>> + ret = i2c_master_send(client, buf, ARRAY_SIZE(buf));
>> + if (ret< 0)
>> + dev_err(&client->dev, "Error %d writing to cec:0x%x\n",
>> ret, addr);
>> +}
>
>
> Has there been any decision on how to split/integrate cec from drm?
> Or is there display stuff located in cec i2c slave (I see HPD in
> ..._detect below)?
not sure, but at least in this case it can't really be decoupled. I
need to use the CEC interface for HPD (as you noticed) and also to
power up the HDMI bits..
>> [...]
>>
>> +static void
>> +tda998x_encoder_save(struct drm_encoder *encoder)
>> +{
>> + DBG("");
>> +}
>> +
>> +static void
>> +tda998x_encoder_restore(struct drm_encoder *encoder)
>> +{
>> + DBG("");
>> +}
>
>
> Hmmm, these DBG("") shouldn't be in upstream kernel code?
>
yeah, I suppose these traces don't add too much value, I can remove them
>> +static bool
>> +tda998x_encoder_mode_fixup(struct drm_encoder *encoder,
>> + const struct drm_display_mode *mode,
>> + struct drm_display_mode *adjusted_mode)
>> +{
>> + return true;
>> +}
>> +
>> +static int
>> +tda998x_encoder_mode_valid(struct drm_encoder *encoder,
>> + struct drm_display_mode *mode)
>> +{
>> + return MODE_OK;
>> +}
>
>
> At least a note would be helpful to see what callbacks are
> not yet done. I guess there will be some kind of mode check
> someday?
Well, some of these drm will assume the fxn ptrs are not null, so we
need something even if it is empty.
I suppose there are must be some upper bounds on pixel clock
supported, which could perhaps be added some day in _mode_valid(). On
the d
Re: Failure to boot...
On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: On Thu, Jan 31, 2013 at 02:13:20PM +, Russell King - ARM Linux wrote: On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP. Now trying to merge your for-next and test. Well, my tip (which is based on Linus' 6abb7c25) also builds and boots fine. Hang on... # CONFIG_ARCH_OMAP2PLUS is not set CONFIG_ARCH_VEXPRESS=y which of course won't boot, and this happens on both oldconfigs because of the change to multiplatform support. And no, the instructions given last time around to add: # 13 Jan 2013: Update for OMAP moving to multiplatform CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=y don't fix it either, it needs more options defined... Linus' tip + Tony's pull [1] request also makes things work on OMAP. Regards, Santosh [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg83084.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: Failure to boot...
On Thu, Jan 31, 2013 at 02:13:20PM +, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: > > Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. > > The pull request from Tony [1] fixed the multi-platform boot issue > > for OMAP. > > > > Now trying to merge your for-next and test. > > Well, my tip (which is based on Linus' 6abb7c25) also builds and > boots fine. > > Hang on... > > # CONFIG_ARCH_OMAP2PLUS is not set > CONFIG_ARCH_VEXPRESS=y > > which of course won't boot, and this happens on both oldconfigs because > of the change to multiplatform support. And no, the instructions given last time around to add: # 13 Jan 2013: Update for OMAP moving to multiplatform CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=y don't fix it either, it needs more options defined... -- 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: Failure to boot...
On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: > Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. > The pull request from Tony [1] fixed the multi-platform boot issue > for OMAP. > > Now trying to merge your for-next and test. Well, my tip (which is based on Linus' 6abb7c25) also builds and boots fine. Hang on... # CONFIG_ARCH_OMAP2PLUS is not set CONFIG_ARCH_VEXPRESS=y which of course won't boot, and this happens on both oldconfigs because of the change to multiplatform support. -- 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: Failure to boot...
On Thursday 31 January 2013 07:30 PM, Santosh Shilimkar wrote: On Thursday 31 January 2013 06:34 PM, Russell King - ARM Linux wrote: On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote: On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: On Thu, Jan 31, 2013 at 09:20:24AM +, Russell King - ARM Linux wrote: On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly. I wish it were that easy but it isn't. I've no idea where to get a version of uboot for my boards which supports that; TI have always supplied updates to uboot for me, and with the current state of TI being afaict in chaos. TI have always supplied a replacement X-Loader with each uboot update. I've no idea what X-Loader is or why both get updated together, but... Moreover, I doubt that the 3430LDP, of which there are multiple versions, will ever see a uboot update. It already suffers from a lack of correct kernel support due to random wiring changes between these versions (the keypad doesn't work correctly) and I've yet to indentify which version it is despite downloading the circuits. So trying to locate the right uboot will be impossible there. So, I'm _stuck_ with uImages for these platforms. Right, so I'm now passing LOADADDR= which allows this to work - and the latest OMAP4430SDP boot result shows almost the same sad broken story. I just tried latest mainline (commit: 04c2eee5) and default config just boots fine. Please read the notes at the bottom of the page, specifically: * Build tree is currently created on an ad-hoc basis from Linus' tip, rmk's development tip and arm-soc for-next branches. This system does *not* build and boot vanilla mainline kernels. It is (as the above says): - Linus' tip - My for-next plus a few other bits - arm-soc for-next all merged together. Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP. Now trying to merge your for-next and test. This is fine as well. I think the issue is the way uImage is created. 'make LOADADDRESS= uImage' actually doesn't work. Am using below method to create an uImage. mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d zImage uImage Will you be able to try this out please ? Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
Pantelis On 1/31/2013 4:52 PM, Pantelis Antoniou wrote: Hi On Jan 31, 2013, at 12:17 PM, Mugunthan V N wrote: On 1/31/2013 1:33 AM, Koen Kooi wrote: Op 30 jan. 2013, om 20:56 heeft Mugunthan V N het volgende geschreven: CPDMA interrupts are not properly acknowledged which leads to interrupt storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver. Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are used for rx and tx respectively. A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly? Existing driver implementation is also complies with TRM. What Pantelis added additionally are non-napi implementation, handled cpdma processed tx and rx processing separately and renamed wr_reg as per TRM naming convention.. Also he has added a dummy reading tx/rx stat which is mentioned in TRM, but this stat is required only when using multichannel for data transfer. Current implementation of CPSW driver uses only channel 0 of Tx and Rx channels respectively for transmission and reading stat doesn't gets any effect in interrupt acknowledgment. Since both tx and rx are processed in same napi api, so i have added interrupt acknowledgment to the same existing api. First of all, this method of not needing to read the stat registers besides when using multichannel for data transfers is never described anywhere in any manual, or in the driver sources. Secondly, I find the method of ack-ing all interrupt sources problematic. Consider the following sequence Rx-interrupt ---> | | | IRQ handler | | schedules NAPI | | disables interrupts --> | cpsw_poll() | | handle Rx Tx-interrupt ---> |-|- | | ack Rx & Tx IRQ | | enable interrupts When will the Tx interrupt get handled? Is it guaranteed that the DMA logic will assert the Tx interrupt when the interrupts are enabled, even though the interrupt was previously acked? It is not clear in the TRM. Need to check with the IP owner with this corner case. Simulating this will be difficult because even if driver misses the interrupt in next rx/tx interrupt it will be serviced. Another problem that I see is that the other interrupts (MISC) are not supposed to be routed to the napi cpsw_poll() function at all. NAPI is for the tx/rx path as far as I know. I agree that napi should not be used for MISC interrupts. Regards Mugunthan V N Regards Mugunthan V N Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot...
On Thursday 31 January 2013 06:34 PM, Russell King - ARM Linux wrote: On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote: On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: On Thu, Jan 31, 2013 at 09:20:24AM +, Russell King - ARM Linux wrote: On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly. I wish it were that easy but it isn't. I've no idea where to get a version of uboot for my boards which supports that; TI have always supplied updates to uboot for me, and with the current state of TI being afaict in chaos. TI have always supplied a replacement X-Loader with each uboot update. I've no idea what X-Loader is or why both get updated together, but... Moreover, I doubt that the 3430LDP, of which there are multiple versions, will ever see a uboot update. It already suffers from a lack of correct kernel support due to random wiring changes between these versions (the keypad doesn't work correctly) and I've yet to indentify which version it is despite downloading the circuits. So trying to locate the right uboot will be impossible there. So, I'm _stuck_ with uImages for these platforms. Right, so I'm now passing LOADADDR= which allows this to work - and the latest OMAP4430SDP boot result shows almost the same sad broken story. I just tried latest mainline (commit: 04c2eee5) and default config just boots fine. Please read the notes at the bottom of the page, specifically: * Build tree is currently created on an ad-hoc basis from Linus' tip, rmk's development tip and arm-soc for-next branches. This system does *not* build and boot vanilla mainline kernels. It is (as the above says): - Linus' tip - My for-next plus a few other bits - arm-soc for-next all merged together. Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP. Now trying to merge your for-next and test. Regards, Santosh [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg83084.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: Failure to boot...
On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote: > On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 09:20:24AM +, Russell King - ARM Linux wrote: >>> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly. >>> >>> I wish it were that easy but it isn't. I've no idea where to get a >>> version of uboot for my boards which supports that; TI have always >>> supplied updates to uboot for me, and with the current state of TI >>> being afaict in chaos. >>> >>> TI have always supplied a replacement X-Loader with each uboot update. >>> I've no idea what X-Loader is or why both get updated together, but... >>> >>> Moreover, I doubt that the 3430LDP, of which there are multiple versions, >>> will ever see a uboot update. It already suffers from a lack of correct >>> kernel support due to random wiring changes between these versions (the >>> keypad doesn't work correctly) and I've yet to indentify which version >>> it is despite downloading the circuits. So trying to locate the right >>> uboot will be impossible there. >>> >>> So, I'm _stuck_ with uImages for these platforms. >> >> Right, so I'm now passing LOADADDR= which allows this to work - and the >> latest OMAP4430SDP boot result shows almost the same sad broken story. >> > I just tried latest mainline (commit: 04c2eee5) and default config > just boots fine. Please read the notes at the bottom of the page, specifically: *Â Build tree is currently created on an ad-hoc basis from Linus' tip, rmk's development tip and arm-soc for-next branches. This system does *not* build and boot vanilla mainline kernels. It is (as the above says): - Linus' tip - My for-next plus a few other bits - arm-soc for-next all merged together. Here's the diffstat between my for-next and the remainder of other stuff that gets built: arch/arm/mach-realview/core.c | 212 arch/arm/mach-realview/core.h |2 + arch/arm/mach-realview/include/mach/platform.h |2 + arch/arm/mach-realview/realview_eb.c| 37 ++- arch/arm/mach-realview/realview_pb11mp.c| 33 ++- arch/arm/mach-realview/realview_pba8.c |3 +- arch/arm/mach-realview/realview_pbx.c |3 +- arch/arm/mach-versatile/core.c | 482 ++- arch/arm/mach-versatile/include/mach/platform.h |6 + arch/arm/mach-versatile/versatile_pb.c | 17 +- drivers/dma/amba-pl08x.c| 26 +- drivers/tty/serial/omap-serial.c| 30 ++ drivers/tty/serial/serial_core.c| 23 +- include/linux/serial_core.h |2 + include/sound/soc-dmaengine.h | 26 + sound/soc/Kconfig |5 + sound/soc/Makefile |3 + sound/soc/sa11x0/Kconfig| 14 + sound/soc/sa11x0/Makefile |5 + sound/soc/sa11x0/sa11x0-assabet.c | 432 + sound/soc/sa11x0/sa11x0-ssp.c | 345 + sound/soc/sa11x0/sa11x0-ssp.h | 11 + sound/soc/soc-dmaengine.c | 591 +++ 23 files changed, 2283 insertions(+), 27 deletions(-) As far as OMAP goes, that's basically additional bits for serial DMA support that I was working on, best pieced back together before the serial driver was majorly reworked a couple of merge windows ago. These have been there for at least the last three months. The rest are for SA11x0 Assabet sound support, and DMA support on Versatile/Realview platforms. > I was looking at your build system output which shows the boot > state "OMAP4430 SDP: fail". Your config seems to be with > CONFIG_ARCH_MULTIPLATFORM=y and indeed this kernel doesn't > boot. Seems to abort very early in boot. Am looking at it. Thanks. > P.S Btw, the load address issue with multi-platform build > was highlighted on the list in past by Tony [1] > > [1] http://www.spinics.net/lists/linux-omap/msg84146.html That's no good to me if it only goes to linux-omap. -- 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: Failure to boot...
On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: On Thu, Jan 31, 2013 at 09:20:24AM +, Russell King - ARM Linux wrote: On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly. I wish it were that easy but it isn't. I've no idea where to get a version of uboot for my boards which supports that; TI have always supplied updates to uboot for me, and with the current state of TI being afaict in chaos. TI have always supplied a replacement X-Loader with each uboot update. I've no idea what X-Loader is or why both get updated together, but... Moreover, I doubt that the 3430LDP, of which there are multiple versions, will ever see a uboot update. It already suffers from a lack of correct kernel support due to random wiring changes between these versions (the keypad doesn't work correctly) and I've yet to indentify which version it is despite downloading the circuits. So trying to locate the right uboot will be impossible there. So, I'm _stuck_ with uImages for these platforms. Right, so I'm now passing LOADADDR= which allows this to work - and the latest OMAP4430SDP boot result shows almost the same sad broken story. I just tried latest mainline (commit: 04c2eee5) and default config just boots fine. I was looking at your build system output which shows the boot state "OMAP4430 SDP: fail". Your config seems to be with CONFIG_ARCH_MULTIPLATFORM=y and indeed this kernel doesn't boot. Seems to abort very early in boot. Am looking at it. Regards, Santosh P.S Btw, the load address issue with multi-platform build was highlighted on the list in past by Tony [1] [1] http://www.spinics.net/lists/linux-omap/msg84146.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] ARM: omap2: register cpufreq-cpu0 device for am33xx
On Thu, Jan 31, 2013 at 09:40:43AM +, AnilKumar, Chimata wrote: > On Wed, Jan 30, 2013 at 20:02:22, Shawn Guo wrote: > > The cpufreq-cpu0 driver changes to instantiate use platform_driver > > mechanism. The patch is an am33xx platform level adaptation for it. > > Tested-by: AnilKumar Ch > Thanks, AnilKumar. > Hi Shawn, > > I have tested your patch on AM335x-EVM, no issues observed. > > I think, better post v3 version which contains this patch > and cpu0-cpufreq driver changes. > > Or > > Post v3 of cpufreq-cpu0 driver changes. > Sorry for forgetting copying you guys. It's been posted as below. http://www.spinics.net/lists/arm-kernel/msg221209.html Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support
Vaibhav,
> > > >
> > > > - if (!pdata) {
> > > > + if (!pdata && !pdev->dev.of_node) {
> > > > dev_err(&pdev->dev, "Could not find platform data\n");
> > > > return -EINVAL;
> > > > }
> > > >
> > > > - if (pdata->adc_init)
> > > > - adc_channels = pdata->adc_init->adc_channels;
> > > > + if (pdev->dev.platform_data) {
> > > > + if (pdata->tsc_init)
> > > > + tsc_wires = pdata->tsc_init->wires;
> > > > +
> > > > + if (pdata->adc_init)
> > > > + adc_channels = pdata->adc_init->adc_channels;
> > > > + } else {
> > > > + node = of_find_node_by_name(pdev->dev.of_node, "tsc");
> > > > + of_property_read_u32(node, "ti,wires", &tsc_wires);
> > > > +
> > > > + node = of_find_node_by_name(pdev->dev.of_node, "adc");
> > > > + of_property_read_u32(node, "ti,adc-channels",
> > > > &adc_channels);
> > > > + }
> > >
> > > Since AM335x is DT only, why is there a platform data codepath and why is
> > > it the first branch it tries? And I guess the next question is related to
> > > the first: why doesn't it work when used with DT? When I copy over the
> > > nodes from the evm.dts to my board I get "tsc tsc: Missing platform data"
> > > in dmesg.
> >
> > This IP came up 1st on AM335x, but it is not platform dependent. The driver
> > can be used on other platforms where-in DT is not supported.
> > According to the maintainers platform data takes precedence over DT. Hence
> > the order.
> >
>
> Rachana,
>
> I see no point adding support for platform_data when you know that none of
> older platforms are going to use this driver and all future platforms _must_
> follow device-tree model.
>
> So I agree that you should remove board file dependency from the driver.
Ok. I will remove support for platform data in the next version of patches.
>
>
> > I do not see "Missing platform data" error msg in the latest driver. I am
> > not able to trace from where this got populated.
> >
>
> Can you share the branch which you have tested?
https://github.com/patilrachna/linux/tree/v3.8_rc3_MFD_TSCADC_DT-v2
Regards,
Rachna
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 1/2] ARM: kernel: update cpuinfo to print SoC model name
On Thu, Jan 31, 2013 at 1:24 AM, Russell King - ARM Linux wrote: > On Wed, Jan 30, 2013 at 02:07:53PM -0500, Nicolas Pitre wrote: >> On Wed, 30 Jan 2013, Ruslan Bilovol wrote: >> >> > Currently, reading /proc/cpuinfo provides userspace with CPU ID of >> > the CPU carrying out the read from the file. >> > Userspace using this information may decide what module >> > to load or how to configure some specific (and processor-depended) >> > settings or so. >> > However, since really different SoCs can share same ARM core, >> > this information currently is not so useful. >> > For example, TI OMAP4460 and OMAP4470 SoCs show the same >> > information in the /proc/cpuinfo whereas they are different. >> > Since in most cases ARM CPU is a part of some system on a chip (SoC), >> > the "cpuinfo" file looks like exactly that place, where this >> > information have to be displayed. >> > >> > So added new line "SoC name" in the "cpuinfo" output for system >> > on a chip name. It is placed between CPU information and machine >> > information, so the file structure looks gracefully (CPU-SoC-Hardware) >> > >> > Example: >> > >> > / # cat proc/cpuinfo >> > [...] >> > CPU variant : 0x2 >> > CPU part: 0xc09 >> > CPU revision: 10 >> > >> > SoC name: OMAP4470 >> > >> > Hardware: OMAP4 Blaze Tablet >> >> Please remove that extra blank line between "SoC name" and "Hardware". >> The blank line after "CPU revision" is fine. >> >> Also, please rename this to "System name". Not all systems are "on >> chip". By using "System name" this is more universally useful. > > You may notice I've already suggested that this should be using the SoC > infrastructure to export this information, which was explicitly designed > to do this. > > If we're going to have one SoC doing one thing and another SoC exporting > this information a completely different way, we're doomed. We need to > make a decision and do it one way and one way only - and that decision > was made when drivers/base/soc.c was merged. > > Unfortunately, I'd forgotten about that when I made my initial comments > about the difference between "CPU" and "SoC". Yes agree - let's stop this discussion at this point. I'm going to learn that soc framework and provide better solution. Unfortunately, I didn't find it when looked into the kernel sources for similar approaches. Regards, Ruslan -- 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 07/10] ARM: OMAP5: clock data: Add OMAP54XX full clock tree and headers
On Wednesday 30 January 2013 11:07 PM, Jon Hunter wrote:
On 01/18/2013 09:27 AM, Santosh Shilimkar wrote:
From: Rajendra Nayak
Add the clock tree related data for OMAP54xx platforms.
[snip]
+ CLK("omap_timer.1", "32k_ck", &sys_32k_ck,
CK_54XX),
+ CLK("omap_timer.2", "32k_ck", &sys_32k_ck,
CK_54XX),
+ CLK("omap_timer.3", "32k_ck", &sys_32k_ck,
CK_54XX),
+ CLK("omap_timer.4", "32k_ck", &sys_32k_ck,
CK_54XX),
+ CLK("omap_timer.5", "32k_ck", &sys_32k_ck,
CK_54XX),
+ CLK("omap_timer.6", "32k_ck", &sys_32k_ck,
CK_54XX),
+ CLK("omap_timer.7", "32k_ck", &sys_32k_ck,
CK_54XX),
+ CLK("omap_timer.8", "32k_ck", &sys_32k_ck,
CK_54XX),
+ CLK("omap_timer.9", "32k_ck", &sys_32k_ck,
CK_54XX),
+ CLK("omap_timer.10", "32k_ck", &sys_32k_ck,
CK_54XX),
+ CLK("omap_timer.11", "32k_ck", &sys_32k_ck,
CK_54XX),
I have been trying to get away from having so many aliases for the same
clock for timers. Here we should replace all of the above and just have ...
+ CLK(NULL, "timer_32k_ck", &sys_32k_ck, CK_54XX),
For more details see [1].
+ CLK("omap_timer.1", "sys_ck", &sys_clkin, CK_54XX),
+ CLK("omap_timer.2", "sys_ck", &sys_clkin, CK_54XX),
+ CLK("omap_timer.3", "sys_ck", &sys_clkin, CK_54XX),
+ CLK("omap_timer.4", "sys_ck", &sys_clkin, CK_54XX),
+ CLK("omap_timer.9", "sys_ck", &sys_clkin, CK_54XX),
+ CLK("omap_timer.10", "sys_ck", &sys_clkin, CK_54XX),
+ CLK("omap_timer.11", "sys_ck", &sys_clkin, CK_54XX),
+ CLK("omap_timer.5", "sys_ck", &dss_syc_gfclk_div,
CK_54XX),
+ CLK("omap_timer.6", "sys_ck", &dss_syc_gfclk_div,
CK_54XX),
+ CLK("omap_timer.7", "sys_ck", &dss_syc_gfclk_div,
CK_54XX),
+ CLK("omap_timer.8", "sys_ck", &dss_syc_gfclk_div,
CK_54XX),
+};
These aliases will not work with device-tree because the device-name is
formatted .. Hence, when configuring a the timer parent
clock via the dmtimer driver it will fail. So it should be more like ...
+ CLK("4ae18000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("48032000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("48034000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("48036000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("40138000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("4013a000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("4013c000.timer", "timer_sys_ck", &sys_clkin, CK_54XX),
+ CLK("4013e000.timer", "timer_sys_ck", &dss_syc_gfclk_div,
CK_54XX),
+ CLK("4803e000.timer", "timer_sys_ck", &dss_syc_gfclk_div,
CK_54XX),
+ CLK("48086000.timer", "timer_sys_ck", &dss_syc_gfclk_div,
CK_54XX),
+ CLK("48088000.timer", "timer_sys_ck", &dss_syc_gfclk_div,
CK_54XX),
For more details see [2].
Thanks Jon. I will update the autogen scripts to generate these
accordingly.
If you would like to test the dmtimer driver on omap5, then you can grab
my omap-test module [3], build it (see README), load it and then ...
# echo 1 > /sys/kernel/debug/omap-test/timer/all
This will perform some basic tests on all the dmtimers. I would do it
myself, but there appears to be several issues getting this to boot on
an ES1.0 (which is probably expected).
Right. This is ES2.0 data, so won't boot on an ES1.0 device.
regards,
Rajendra
Cheers
Jon
[1] http://www.spinics.net/lists/linux-omap/msg71272.html
[2] https://patchwork.kernel.org/patch/1204351/
[3] https://github.com/jonhunter/omap-test
--
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] ARM: omap4: clock data: Add missing clkdm association for dpll_usb
Hi Paul, dpll_usb needs the clkdm association so the clkdm can be turned on before a relock. All other dplls for omap4 belong to the ALWON (always on) domain. The association was present as part of the older data file (clock44xx_data.c) but looks like was accidently dropped with the common clk convertion. Thanks, queued for v3.8-rc fixes. I just realized that apart from adding the missing .clkdm_name, I also need to populate a .init as part of clk_ops for dpll_usb so the clockdomain lookup can then happen based on the .clkdm_name. I have updated the $Subject patch and posted a v2 (http://marc.info /?l=linux-omap&m=135963212530790&w=2). Would it be possible for you to pick the v2 instead and drop this one from your fixes branch. regards, Rajendra - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: omap4: clock data: Add missing clkdm association for dpll_usb
dpll_usb needs the clkdm association so the clkdm can be
turned on before a relock. All other dplls for omap4 belong
to the ALWON (always on) domain.
The association was present as part of the older data file
(clock44xx_data.c) but looks like got accidently dropped with
the common clk convertion.
More details of the patch which fixed this up in the older
data file can be dound here..
http://www.spinics.net/lists/linux-omap/msg63076.html
Adding the .clkdm_name as part of the clk_hw_omap struct also
means a new .init needs to be part of the clk_ops for dpll_usb
to initialise the clkdm.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/cclock44xx_data.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index a2cc046..e71a19c 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -595,15 +595,26 @@ static const char *dpll_usb_ck_parents[] = {
static struct clk dpll_usb_ck;
+static const struct clk_ops dpll_usb_ck_ops = {
+ .enable = &omap3_noncore_dpll_enable,
+ .disable= &omap3_noncore_dpll_disable,
+ .recalc_rate= &omap3_dpll_recalc,
+ .round_rate = &omap2_dpll_round_rate,
+ .set_rate = &omap3_noncore_dpll_set_rate,
+ .get_parent = &omap2_init_dpll_parent,
+ .init = &omap2_init_clk_clkdm,
+};
+
static struct clk_hw_omap dpll_usb_ck_hw = {
.hw = {
.clk = &dpll_usb_ck,
},
.dpll_data = &dpll_usb_dd,
+ .clkdm_name = "l3_init_clkdm",
.ops= &clkhwops_omap3_dpll,
};
-DEFINE_STRUCT_CLK(dpll_usb_ck, dpll_usb_ck_parents, dpll_ck_ops);
+DEFINE_STRUCT_CLK(dpll_usb_ck, dpll_usb_ck_parents, dpll_usb_ck_ops);
static const char *dpll_usb_clkdcoldo_ck_parents[] = {
"dpll_usb_ck",
--
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 RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.
Hi, On Thursday 31 January 2013 04:50 PM, Vivek Gautam wrote: With device tree support in place for dwc3-core layer, it gets PHY from "synopsis-dwc3" node. Some controllers may not have separate memory maps and interrupts for dwc3 core and platform glue layers. In such case only glue layer's node will exist. Not really. As long as you have dwc3 core as a separate device, you can add a node for it. Just that the glue should create a device for dwc3 core using of_platform_populate.(You can have a look at drivers/usb/dwc3/dwc3-omap.c in usb-next) Moreover, SoCs having multiple dwc3 controllers will have multiple PHYs, which eventually be added using usb_add_phy_dev(), and not using usb_add_phy(). So each dwc3 controller won't be able to get PHYs by simply calling devm_usb_get_phy() also. No. We have added usb_get_phy_dev() for that purpose in the case of non-dt. I think, instead you can have a patch to use devm_usb_get_phy_dev() here and in exynos platform specific code use usb_bind_phy() to bind the phy and controller till you change it to dt. In such cases, dwc3 should expect PHYs from its parent's node. NAK. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v2 13/18] ARM: OMAP2+: AM33XX: timer: Interchance clkevt and clksrc timers
On Wed, Jan 30, 2013 at 23:19:34, Hunter, Jon wrote: > > By the way, this need to be applied on top of the fix I sent yesterday > to pass the property. > Ok. Thanks for pointing this out. -- 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: OMAP4 PM bootloader dependency problems
Tero, On Thursday 31 January 2013 02:30 PM, Tero Kristo wrote: Personally I don't like too much to have just extra spam during boot, which in many cases is even unnecessary (e.g. people who actually have good u-boot in use.) Personally I would like to have some sort of test during boot which detects broken PM and maybe prevents core idle completely if this is the case. Alternatively we can add extra info to the failed suspend dump and mention a good u-boot to try out (v2012-07 or newer.) If we could detect boot loader version from kernel side, that would work also. Given that there is no easy way to say for sure the bootloader is the cause for broken PM in the kernel, neither is it possible to know the bootloader version, why don't we do this. Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note that it isn't enabled by default in omap2plus_defconfig. Also throw one when a suspend fails, saying bootloader *could be* a possible cause specifying the right version to be used. That should give enough hints to folks still using old bootloaders and testing PM. Does that sound good? regards, Rajendra -- 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/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
Hi On Jan 31, 2013, at 12:17 PM, Mugunthan V N wrote: > On 1/31/2013 1:33 AM, Koen Kooi wrote: >> Op 30 jan. 2013, om 20:56 heeft Mugunthan V N het >> volgende geschreven: >> >>> CPDMA interrupts are not properly acknowledged which leads to interrupt >>> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver. >>> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are >>> used for rx and tx respectively. >> A brief inspection shows that this still isn't following the TRM, but >> Pantelis' patch does. Can you please fix this driver to follow the TRM and >> make it work on both PG1.0 and PG2.0 instead of papering over bugs instead >> of fixing them properly? > Existing driver implementation is also complies with TRM. What Pantelis added > additionally are non-napi implementation, handled cpdma processed tx and rx > processing separately and renamed wr_reg as per TRM naming convention.. Also > he > has added a dummy reading tx/rx stat which is mentioned in TRM, but this stat > is required only when using multichannel for data transfer. Current > implementation > of CPSW driver uses only channel 0 of Tx and Rx channels respectively for > transmission > and reading stat doesn't gets any effect in interrupt acknowledgment. > > Since both tx and rx are processed in same napi api, so i have added interrupt > acknowledgment to the same existing api. > First of all, this method of not needing to read the stat registers besides when using multichannel for data transfers is never described anywhere in any manual, or in the driver sources. Secondly, I find the method of ack-ing all interrupt sources problematic. Consider the following sequence Rx-interrupt ---> | | | IRQ handler | | schedules NAPI | | disables interrupts --> | cpsw_poll() | | handle Rx Tx-interrupt ---> |-|- | | ack Rx & Tx IRQ | | enable interrupts When will the Tx interrupt get handled? Is it guaranteed that the DMA logic will assert the Tx interrupt when the interrupts are enabled, even though the interrupt was previously acked? It is not clear in the TRM. Another problem that I see is that the other interrupts (MISC) are not supposed to be routed to the napi cpsw_poll() function at all. NAPI is for the tx/rx path as far as I know. > Regards > Mugunthan V N Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v2 12/18] ARM: OMAP2+: timer: Add suspend-resume callbacks for clockevent device
On Wed, Jan 30, 2013 at 23:16:34, Hunter, Jon wrote: > > Ok fair enough. By the way, I posted a patch today [1] that will use the > hwmod name as the clockevent timer name. Care to try on top of that > patch and then we can eliminate the sprintf. > Thanks. Will try it out later today. Regards, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.
With device tree support in place for dwc3-core layer,
it gets PHY from "synopsis-dwc3" node.
Some controllers may not have separate memory maps and interrupts
for dwc3 core and platform glue layers. In such case only glue
layer's node will exist.
Moreover, SoCs having multiple dwc3 controllers will have multiple
PHYs, which eventually be added using usb_add_phy_dev(), and not
using usb_add_phy(). So each dwc3 controller won't be able to
get PHYs by simply calling devm_usb_get_phy() also.
In such cases, dwc3 should expect PHYs from its parent's node.
So, adding provision for getting PHY from platform specific
device tree node.
Signed-off-by: Vivek Gautam
---
Based on 'usb-next'.
drivers/usb/dwc3/core.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 094..75439c0 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -423,6 +423,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 0);
dwc->usb3_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 1);
+ } else if (dev->parent->of_node) {
+ dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev->parent,
+ "usb-phy", 0);
+ dwc->usb3_phy = devm_usb_get_phy_by_phandle(dev->parent,
+ "usb-phy", 1);
} else {
dwc->usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
dwc->usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
--
1.7.6.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 1/2] drivers: net: cpsw: Add helper functions for VLAN ALE implementation
On 1/31/2013 3:32 AM, Francois Romieu wrote:
Mugunthan V N :
[...]
diff --git a/drivers/net/ethernet/ti/cpsw_ale.c
b/drivers/net/ethernet/ti/cpsw_ale.c
index 0e9ccc2..18b88ce 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
[...]
@@ -274,19 +292,26 @@ int cpsw_ale_flush(struct cpsw_ale *ale, int port_mask)
return 0;
}
-int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port, int flags)
+int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port,
+ int flags, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
int idx;
- cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
+ if (flags & ALE_VLAN) {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_VLAN_ADDR);
+ cpsw_ale_set_vlan_id(ale_entry, vid);
+ } else {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
+ }
+
[...]
+ if (flags & ALE_VLAN) {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_VLAN_ADDR);
+ cpsw_ale_set_vlan_id(ale_entry, vid);
+ } else {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
+ }
+
It could be fctored out.
Are you mentioning to have static inline function for the above two
statements above?
[...]
@@ -362,6 +395,55 @@ int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr, int
port_mask)
return 0;
}
+int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port, int untag,
+ int reg_mcast, int unreg_mcast)
+{
[...]
+int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port_mask)
[...]
Patch #2 doesn't use the returned status code.
Will modify the prototype to return void
Regards
Mugunthan V N
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] drivers: net:ethernet: cpsw: add support for VLAN
On 1/31/2013 3:32 AM, Francois Romieu wrote:
Mugunthan V N :
[...]
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..99696bf 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -24,6 +24,8 @@ Required properties:
Optional properties:
- ti,hwmods : Must be "cpgmac0"
- no_bd_ram : Must be 0 or 1
+- default_vlan : Specifies Default VLAN for non tagged packets
+ ALE processing
Isn't it a device-tree hack for what should belong to a common API ?
Its a hardware feature which stack will not be aware of. It is used in
the ALE filtering
process with a non-tagged packet arrives.
[...]
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index a40750e..6c66f01 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
[...]
@@ -607,14 +611,41 @@ static void cpsw_slave_open(struct cpsw_slave *slave,
struct cpsw_priv *priv)
}
}
+static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
+{
+ writel(priv->data.default_vlan, &priv->host_port_regs->port_vlan);
+ if (priv->version == CPSW_VERSION_1) {
+ slave_write(&priv->slaves[0], priv->data.default_vlan,
+ CPSW1_PORT_VLAN);
+ slave_write(&priv->slaves[1], priv->data.default_vlan,
+ CPSW1_PORT_VLAN);
+ } else {
+ slave_write(&priv->slaves[0], priv->data.default_vlan,
+ CPSW2_PORT_VLAN);
+ slave_write(&priv->slaves[1], priv->data.default_vlan,
+ CPSW2_PORT_VLAN);
+ }
+ cpsw_ale_add_vlan(priv->ale, priv->data.default_vlan,
+ ALE_ALL_PORTS << priv->host_port,
+ ALE_ALL_PORTS << priv->host_port,
+ ALE_ALL_PORTS << priv->host_port,
+ (BIT(1) | BIT(2)) << priv->host_port);
+}
static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
{
const int vlan = priv->data.default_vlan;
const int port = priv->host_port;
u32 reg;
int i;
reg = (priv->version == CPSW_VERSION_1) ? CPSW1_PORT_VLAN :
CPSW2_PORT_VLAN;
writel(vlan, &priv->host_port_regs->port_vlan);
for (int i = 0; i < 2; i++)
slave_write(priv->slaves + i, vlan, reg);
cpsw_ale_add_vlan(priv->ale, vlan, ALE_ALL_PORTS << port,
ALE_ALL_PORTS << port, ALE_ALL_PORTS << port,
(BIT(1) | BIT(2)) << port);
}
... or somewhere between both. Your call.
Will modify the code as this looks simpler
[...]
@@ -933,6 +967,55 @@ static void cpsw_ndo_poll_controller(struct net_device
*ndev)
}
#endif
+static inline void cpsw_add_vlan_ale_entry(struct cpsw_priv *priv,
+ unsigned short vid)
+{
+ cpsw_ale_add_vlan(priv->ale, vid, ALE_ALL_PORTS << priv->host_port,
+ 0, ALE_ALL_PORTS << priv->host_port,
+ (BIT(1) | BIT(2)) << priv->host_port);
"(BIT(1) | BIT(2))" is repeated a couple of times.
Will replace with port number defines.
[...]
+static int cpsw_ndo_vlan_rx_add_vid(struct net_device *ndev,
+ unsigned short vid)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+
+ if (vid == priv->data.default_vlan)
+ return 0;
+
+ spin_lock(&priv->lock);
+
+ dev_info(priv->dev, "Adding vlanid %d to vlan filter\n", vid);
+ cpsw_add_vlan_ale_entry(priv, vid);
+
+ spin_unlock(&priv->lock);
+ return 0;
+}
+
+static int cpsw_ndo_vlan_rx_kill_vid(struct net_device *ndev,
+ unsigned short vid)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+
+ if (vid == priv->data.default_vlan)
+ return 0;
+
+ spin_lock(&priv->lock);
+
+ dev_info(priv->dev, "removing vlanid %d from vlan filter\n", vid);
+ cpsw_ale_del_vlan(priv->ale, vid, 0);
+ cpsw_ale_del_ucast(priv->ale, priv->mac_addr,
+ priv->host_port, ALE_VLAN, vid);
+ cpsw_ale_del_mcast(priv->ale, priv->ndev->broadcast, 0, ALE_VLAN, vid);
+
+ spin_unlock(&priv->lock);
What are you trying to achieve with the lock ?
It is not used anywhere else and both cpsw_ndo_vlan_rx_{add, kill}_vid are
called under RTNL.
Will remove the lock from both apis
Regards
Mugunthan V N
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot...
On Thu, Jan 31, 2013 at 09:20:24AM +, Russell King - ARM Linux wrote: > On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: > > Better yet (IMHO): just enable the zboot command in U-Boot to let you > > boot a zImage binary directly. > > I wish it were that easy but it isn't. I've no idea where to get a > version of uboot for my boards which supports that; TI have always > supplied updates to uboot for me, and with the current state of TI > being afaict in chaos. > > TI have always supplied a replacement X-Loader with each uboot update. > I've no idea what X-Loader is or why both get updated together, but... > > Moreover, I doubt that the 3430LDP, of which there are multiple versions, > will ever see a uboot update. It already suffers from a lack of correct > kernel support due to random wiring changes between these versions (the > keypad doesn't work correctly) and I've yet to indentify which version > it is despite downloading the circuits. So trying to locate the right > uboot will be impossible there. > > So, I'm _stuck_ with uImages for these platforms. Right, so I'm now passing LOADADDR= which allows this to work - and the latest OMAP4430SDP boot result shows almost the same sad broken story. -- 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/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
On 1/31/2013 1:33 AM, Koen Kooi wrote: Op 30 jan. 2013, om 20:56 heeft Mugunthan V N het volgende geschreven: CPDMA interrupts are not properly acknowledged which leads to interrupt storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver. Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are used for rx and tx respectively. A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly? Existing driver implementation is also complies with TRM. What Pantelis added additionally are non-napi implementation, handled cpdma processed tx and rx processing separately and renamed wr_reg as per TRM naming convention.. Also he has added a dummy reading tx/rx stat which is mentioned in TRM, but this stat is required only when using multichannel for data transfer. Current implementation of CPSW driver uses only channel 0 of Tx and Rx channels respectively for transmission and reading stat doesn't gets any effect in interrupt acknowledgment. Since both tx and rx are processed in same napi api, so i have added interrupt acknowledgment to the same existing api. Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: omap2: register cpufreq-cpu0 device for am33xx
On Wed, Jan 30, 2013 at 20:02:22, Shawn Guo wrote:
> The cpufreq-cpu0 driver changes to instantiate use platform_driver
> mechanism. The patch is an am33xx platform level adaptation for it.
Tested-by: AnilKumar Ch
Hi Shawn,
I have tested your patch on AM335x-EVM, no issues observed.
I think, better post v3 version which contains this patch
and cpu0-cpufreq driver changes.
Or
Post v3 of cpufreq-cpu0 driver changes.
Thanks
AnilKumar
> Signed-off-by: Shawn Guo
> ---
> arch/arm/mach-omap2/board-generic.c |1 +
> arch/arm/mach-omap2/cclock33xx_data.c |2 +-
> arch/arm/mach-omap2/common.h |1 +
> arch/arm/mach-omap2/io.c |8
> 4 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index 53cb380b..b945480 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -139,6 +139,7 @@ DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened
> Device Tree)")
> .init_irq = omap_intc_of_init,
> .handle_irq = omap3_intc_handle_irq,
> .init_machine = omap_generic_init,
> + .init_late = am33xx_init_late,
> .timer = &omap3_am33xx_timer,
> .dt_compat = am33xx_boards_compat,
> MACHINE_END
> diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
> b/arch/arm/mach-omap2/cclock33xx_data.c
> index ea64ad6..acb1620 100644
> --- a/arch/arm/mach-omap2/cclock33xx_data.c
> +++ b/arch/arm/mach-omap2/cclock33xx_data.c
> @@ -850,7 +850,7 @@ static struct omap_clk am33xx_clks[] = {
> CLK(NULL, "dpll_core_m5_ck", &dpll_core_m5_ck,
> CK_AM33XX),
> CLK(NULL, "dpll_core_m6_ck", &dpll_core_m6_ck,
> CK_AM33XX),
> CLK(NULL, "dpll_mpu_ck", &dpll_mpu_ck, CK_AM33XX),
> - CLK("cpu0", NULL, &dpll_mpu_ck, CK_AM33XX),
> + CLK("cpufreq-cpu0.0", NULL, &dpll_mpu_ck, CK_AM33XX),
> CLK(NULL, "dpll_mpu_m2_ck", &dpll_mpu_m2_ck,
> CK_AM33XX),
> CLK(NULL, "dpll_ddr_ck", &dpll_ddr_ck, CK_AM33XX),
> CLK(NULL, "dpll_ddr_m2_ck", &dpll_ddr_m2_ck,
> CK_AM33XX),
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 948bcaa..e3355df5 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -106,6 +106,7 @@ void omap2430_init_late(void);
> void omap3430_init_late(void);
> void omap35xx_init_late(void);
> void omap3630_init_late(void);
> +void am33xx_init_late(void);
> void am35xx_init_late(void);
> void ti81xx_init_late(void);
> void omap4430_init_late(void);
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 2c3fdd6..0e67711 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -535,6 +535,14 @@ void __init omap3630_init_late(void)
> omap2_clk_enable_autoidle_all();
> }
>
> +void __init am33xx_init_late(void)
> +{
> + struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> +
> + if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0))
> + platform_device_register_full(&devinfo);
> +}
> +
> void __init am35xx_init_late(void)
> {
> omap_mux_late_init();
> --
> 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 0/5] ARM: OMAP2+: System timer updates
On Wednesday 30 January 2013 10:34 PM, Jon Hunter wrote: This series consists mainly of clean-ups for clockevents and clocksource timers on OMAP2+ devices. The most significant change in functionality comes from the 5th patch which is changing the selection of the clocksource timer for OMAP3 and AM335x devices when gptimers are used for clocksource. This change came about from Vaibhav Bedia's series for AM335x [1]. See patch for more details on the exact nature of the change. Boot tested with and without device-tree on OMAP2420 H4, OMAP3430 SDP, OMAP3430 Beagle Board, OMAP4430 SDP and AM335x EVM (AM335x only supports device-tree boot). This series is based upon ARM-SoC next branch. [1] https://patchwork.kernel.org/patch/1921421/ Jon Hunter (5): ARM: OMAP2+: Display correct system timer name ARM: OMAP2+: Remove hard-coded test on timer ID ARM: OMAP2+: Simplify system timer clock definitions ARM: OMAP2+: Simplify system timers definitions ARM: OMAP3: Update clocksource timer selection Nice work Jon. All the patches in the series looks good to my eyes. Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 0/3] Add device tree support for NAND flash in am335x-evm
Benoit, On Thu, Jan 24, 2013 at 13:32:26, Philip, Avinash wrote: > This patch series adds device tree support for NAND flash in am335x-evm. > Also ELM node is populated in device tree and been used for BCH error > correction in NAND flash part. Also this patch series ensures RBL ecc > layout maintained in Linux kernel with BCH8 ecc scheme. > > This patch series based on [1] and depends on [2]. > > 1. > http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=tree;h=refs/heads/for_3.9/dts;hb=refs/heads/for_3.9/dts > > 2.mtd: devices: elm: Removes literals in elm DT node > https://lkml.org/lkml/2013/1/24/30 > Can you accept this patch series so that NAND flash with BCH support for am335x-evm available in 3.9. Thanks Avinash > Philip Avinash (1): > ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm > > Philip, Avinash (2): > ARM: dts: AM33XX: Add ELM node > ARM: dts: AM33XX: Add GPMC node > > arch/arm/boot/dts/am335x-evm.dts | 98 > +- > arch/arm/boot/dts/am33xx.dtsi| 20 > 2 files changed, 117 insertions(+), 1 deletion(-) > > -- > 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] mmc: omap_hsmmc: MAINTAINERS: update
On Thu, Jan 31, 2013 at 2:22 PM, Balaji T K wrote: > Update Maintainer email for omap_hsmmc, > as Venkatraman will no longer be able to maintain omap_hsmmc driver. > > Signed-off-by: Venkatraman S > Signed-off-by: Balaji T K Balaji, My sign-off is incorrect, as I did not write this patch. Of course it would great to have a maintainer for this, hence you can add my Acked-by: Venkatraman S > --- > MAINTAINERS |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot...
On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: > Better yet (IMHO): just enable the zboot command in U-Boot to let you > boot a zImage binary directly. I wish it were that easy but it isn't. I've no idea where to get a version of uboot for my boards which supports that; TI have always supplied updates to uboot for me, and with the current state of TI being afaict in chaos. TI have always supplied a replacement X-Loader with each uboot update. I've no idea what X-Loader is or why both get updated together, but... Moreover, I doubt that the 3430LDP, of which there are multiple versions, will ever see a uboot update. It already suffers from a lack of correct kernel support due to random wiring changes between these versions (the keypad doesn't work correctly) and I've yet to indentify which version it is despite downloading the circuits. So trying to locate the right uboot will be impossible there. So, I'm _stuck_ with uImages for these platforms. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: OMAP2+: Simplify system timers definitions
On 01/30/13 19:04, Jon Hunter wrote: > There is a lot of redundancy in the definitions for the various system > timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init() > function is the same as the omap3_gp_gptimer_timer_init() function and the > function omap2_sync32k_timer_init() can be re-used for OMAP4/5 devices. > Therefore, consolidate the definitions to simplify the code. > > Signed-off-by: Jon Hunter Acked-by: Igor Grinberg -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: OMAP3: Update clocksource timer selection
On 01/30/13 19:04, Jon Hunter wrote: > When booting with device-tree for OMAP3 and AM335x devices and a gptimer > is used as the clocksource (which is always the case for AM335x), a > gptimer located in a power domain that is not always-on is selected. > Ideally we should use a gptimer located in a power domain that is always > on (such as the wake-up domain) so that time can be maintained during a > kernel suspend without keeping on additional power domains unnecessarily. > > In order to fix this so that we can select a gptimer located in a power > domain that is always-on, the following changes were made ... > 1. Currently, only when selecting a gptimer to use for a clockevent >timer, do we pass a timer property that can be used to select a >specific gptimer. Change this so that we can pass a property when >selecting a gptimer to use for a clocksource timer too. > 2. Currently, when selecting either a gptimer to use for a clockevent >timer or a clocksource timer and no timer property is passed, then >the first available timer is selected regardless of the properties >it has. Change this so that if no properties are passed, then a timer >that does not have additional features (such as always-on, dsp-irq, >pwm, and secure) is selected. > > Please note that using a gptimer for both clocksource and clockevents > can have a system power impact during idle. The reason being is that > OMAP and AMxxx devices typically only have one gptimer in a power domain > that is always-on. Therefore when the kernel is idle both the clocksource > and clockevent timers will be active and this will keep additional power > domains on. During kernel suspend, only the clocksource timer is active > and therefore, it is better to use a gptimer in a power domain that is > always-on for clocksource. This should explain the gptimer number switch in the #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) section below, right? I would really like to see that clearly stated in the commit message. For instance: ... it is better to use a gptimer in a power domain that is always-on for clocksource. Therefore we switch to use the first gptimer for clocksource and the second for clockevents. > > Signed-off-by: Jon Hunter Apart from above, Acked-by: Igor Grinberg > --- > arch/arm/mach-omap2/timer.c | 32 +--- > 1 file changed, 21 insertions(+), 11 deletions(-) > > diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c > index af20be7..acf9f82 100644 > --- a/arch/arm/mach-omap2/timer.c > +++ b/arch/arm/mach-omap2/timer.c [...] > @@ -557,19 +567,19 @@ void __init omap##name##_sync32k_timer_init(void) > \ > #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP4) || > \ > defined(CONFIG_SOC_OMAP5) > OMAP_SYS_32K_TIMER_INIT(2, 1, "timer_32k_ck", "ti,timer-alwon", > - 2, "timer_sys_ck"); > + 2, "timer_sys_ck", NULL); > #endif > > #ifdef CONFIG_ARCH_OMAP3 > OMAP_SYS_32K_TIMER_INIT(3, 1, "timer_32k_ck", "ti,timer-alwon", > - 2, "timer_sys_ck"); > + 2, "timer_sys_ck", NULL); > OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure", > - 2, "timer_sys_ck"); > + 2, "timer_sys_ck", NULL); > #endif /* CONFIG_ARCH_OMAP3 */ > > #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) > -OMAP_SYS_GP_TIMER_INIT(3, 1, "timer_sys_ck", "ti,timer-alwon", > -2, "timer_sys_ck"); > +OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL, > +1, "timer_sys_ck", "ti,timer-alwon"); > #endif > > #ifdef CONFIG_ARCH_OMAP4 > -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 PM bootloader dependency problems
On Wed, 2013-01-30 at 17:15 +, Paul Walmsley wrote: > Hi Tero et al., > > On Tue, 22 Jan 2013, Paul Walmsley wrote: > > > As we've discussed, there are known bootloader dependencies with the OMAP4 > > PM retention idle code, introduced in v3.8. Boards booted with u-boot > > versions even as recent as 2011 won't enter retention idle correctly; for > > example: > > > > > > http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt > > ... > > > Barring that, what I'd like to see is a patch for v3.8-rc fixes that adds > > a warning, printed to the kernel console, during boot. The warning should > > state that the OMAP4 PM code only works with certain bootloaders, and > > should identify the minimum u-boot release needed for OMAP4 full-chip > > retention idle to work. > > Any progress on this one? Time is getting very short to get this into > v3.8-rc fixes, and it's important to get this into v3.8 so we don't > have users expecting chip power management to work correctly with most > u-boot versions that are out in the field. > > All we should need for v3.8-rc are a few pr_warn()s that execute during > OMAP4 PM init, noting that the OMAP4 chip power management doesn't work > correctly with many bootloaders, due to missing code in the kernel to > properly reset and initialize some devices, and noting the first u-boot > version that is known to work correctly. Personally I don't like too much to have just extra spam during boot, which in many cases is even unnecessary (e.g. people who actually have good u-boot in use.) Personally I would like to have some sort of test during boot which detects broken PM and maybe prevents core idle completely if this is the case. Alternatively we can add extra info to the failed suspend dump and mention a good u-boot to try out (v2012-07 or newer.) If we could detect boot loader version from kernel side, that would work also. -Tero > > Otherwise there's a very real risk that folks out there will waste lots of > time trying to figure out why power management doesn't work as they > expect. To respect our users, we shouldn't put them in that situation. > > > - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: omap_hsmmc: MAINTAINERS: update
Update Maintainer email for omap_hsmmc, as Venkatraman will no longer be able to maintain omap_hsmmc driver. Signed-off-by: Venkatraman S Signed-off-by: Balaji T K --- MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 92e726c..f319237 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5498,7 +5498,7 @@ S:Maintained F: drivers/mmc/host/omap.c OMAP HS MMC SUPPORT -M: Venkatraman S +M: Balaji T K L: linux-...@vger.kernel.org L: linux-omap@vger.kernel.org S: Maintained -- 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 v3] ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check" bug
On Thu, Jan 31, 2013 at 12:58:36, Koen Kooi wrote:
>
> Op 30 jan. 2013, om 15:39 heeft Hebbar Gururaja het
> volgende geschreven:
>
> > am33xx_cm_wait_module_ready() checks if register offset is NULL.
> >
> > int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
> > {
> > int i = 0;
> >
> > if (!clkctrl_offs)
> > return 0;
> >
> > In case of AM33xx, CLKCTRL register offset for different clock domains
> > are not uniformly placed. An example of this would be the RTC clock
> > domain with CLKCTRL offset at 0x00.
> > In such cases the module ready check is skipped which leads to a data
> > abort during boot-up when RTC registers is accessed.
> >
> > Remove this check here to avoid checking module readiness for modules
> > with clkctrl register offset at 0x00.
> >
> > Signed-off-by: Hebbar Gururaja
>
> I can confirm that this fixes the crash on boot with CONFIG_RTC_DRV_OMAP=y
> with 3.8-rc5
Could you please share the crash log for my reference?
>
> regards,
>
> Koen
Regards,
Gururaja
--
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
