Re: [PATCH 2/2] pwm: use PWM_LOOKUP to set the period and polarity
On Wed, Apr 09, 2014 at 08:04:09PM +0200, Alexandre Belloni wrote:
> Now that the PWM core is able to set the period and polarity based on
> the lookup table, add those to PWM_LOOKUP to ease their usage.
I would prefer if this change was made in a non-atomic manner.
1. Add new infrastructure
2. Update users individually
3. Remove old infrastructure
>
> Signed-off-by: Alexandre Belloni
> ---
> Documentation/pwm.txt | 3 ++-
> arch/arm/mach-omap2/board-omap3beagle.c| 3 ++-
> arch/arm/mach-pxa/hx4700.c | 3 ++-
> arch/arm/mach-shmobile/board-armadillo800eva.c | 3 ++-
> include/linux/pwm.h| 4 +++-
> 5 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
> index 93cb97974986..f38f99cda64f 100644
> --- a/Documentation/pwm.txt
> +++ b/Documentation/pwm.txt
> @@ -19,7 +19,8 @@ should instead register a static mapping that can be used
> to match PWM
> consumers to providers, as given in the following example:
>
> static struct pwm_lookup board_pwm_lookup[] = {
> - PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL),
> + PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL,
> +5, PWM_POLARITY_NORMAL),
> };
>
> static void __init board_init(void)
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
> b/arch/arm/mach-omap2/board-omap3beagle.c
> index d6ed819ff15c..54c135a5b4f7 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -61,7 +61,8 @@
>
> static struct pwm_lookup pwm_lookup[] = {
> /* LEDB -> PMU_STAT */
> - PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat"),
> + PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat",
> +7812500, PWM_POLARITY_NORMAL),
> };
>
> static struct led_pwm pwm_leds[] = {
> diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
> index a7c30eb0c8db..c66ad4edc5e3 100644
> --- a/arch/arm/mach-pxa/hx4700.c
> +++ b/arch/arm/mach-pxa/hx4700.c
> @@ -574,7 +574,8 @@ static struct platform_device backlight = {
> };
>
> static struct pwm_lookup hx4700_pwm_lookup[] = {
> - PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL),
> + PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL,
> +30923, PWM_POLARITY_NORMAL),
> };
>
> /*
> diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
> b/arch/arm/mach-shmobile/board-armadillo800eva.c
> index 2858f380beae..e2c4c5010f19 100644
> --- a/arch/arm/mach-shmobile/board-armadillo800eva.c
> +++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
> @@ -416,7 +416,8 @@ static struct platform_device pwm_device = {
> };
>
> static struct pwm_lookup pwm_lookup[] = {
> - PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL),
> + PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL,
> +3, PWM_POLARITY_NORMAL),
> };
>
> /* LCDC and backlight */
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index 2f45e2fe5b93..e90628cac8fa 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -278,12 +278,14 @@ struct pwm_lookup {
> enum pwm_polarity polarity;
> };
>
> -#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id) \
> +#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id, _period, _polarity) \
> { \
> .provider = _provider, \
> .index = _index,\
> .dev_id = _dev_id, \
> .con_id = _con_id, \
> + .period = _period, \
> + .polarity = _polarity \
> }
>
> #if IS_ENABLED(CONFIG_PWM)
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pwm: add period and polarity to struct pwm_lookup
On 09/04/2014 at 20:37:06 +0100, Russell King - ARM Linux wrote : > On Wed, Apr 09, 2014 at 08:04:08PM +0200, Alexandre Belloni wrote: > > Adds a period and a polarity member to struct pwm_lookup so that when > > performing > > a lookup using the lookup table instead of device tree, we are able to set > > the > > period and the polarity accordingly like what is done in > > of_pwm_xlate_with_flags. > > > > Signed-off-by: Alexandre Belloni > > --- > > drivers/pwm/core.c | 5 + > > include/linux/pwm.h | 2 ++ > > 2 files changed, 7 insertions(+) > > > > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c > > index a80471399c20..206e5996359c 100644 > > --- a/drivers/pwm/core.c > > +++ b/drivers/pwm/core.c > > @@ -663,6 +663,11 @@ struct pwm_device *pwm_get(struct device *dev, const > > char *con_id) > > > > if (chip) > > pwm = pwm_request_from_chip(chip, index, con_id ?: dev_id); > > + if (IS_ERR(pwm)) > > + return pwm; > > + > > + pwm_set_period(pwm, p->period); > > + pwm_set_polarity(pwm, p->polarity); > > > > mutex_unlock(&pwm_lookup_lock); > > Clearly, this is not right. Returning while leaving the mutex locked? > No. > Sure, I will fix that crap, sorry about that and thanks for pointing it out. > The second issue is... with _just_ this patch applied, we end up with > "period" and "polarity" presumably initialised to zero, which means we > now end up with the above explicitly setting the period and polarity as > such. Isn't that going to change the behaviour of this? > I actually checked that. For the polarity, for now, it is assumed that it is normal unless specified otherwise. The only driver that was supporting inverting it using platform_data is pwm-renesas-tpu. It is used by board-armadillo800eva.c that I am modifying now (and I just now realise that I forgot to invert it). The only PWM controller that I know of that by default has its polarity inversed is the allwinner one and in the driver I submitted, I actually switch it to normal polarity in the probe instead of e.g. doing pwm->polarity = PWM_POLARITY_INVERSED; For the period, all the driver are assuming 0 after initialization. I think this is not specified. If you think that may be a concern then I suggest creating another macro and using a bitfield to know which value is set. I would also argue that when using device tree, of_pwm_xlate_with_flags() will set the period and the polarity unconditionally, this is replicating that behaviour. However, I could agree that we may need to test for pwm->chip->ops->set_polarity before calling pwm_set_polarity as we will get an error if it is NULL (but we actually discard that return value). -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe 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/2] pwm: add period and polarity to struct pwm_lookup
On Wed, Apr 09, 2014 at 08:04:08PM +0200, Alexandre Belloni wrote: > Adds a period and a polarity member to struct pwm_lookup so that when > performing > a lookup using the lookup table instead of device tree, we are able to set the > period and the polarity accordingly like what is done in > of_pwm_xlate_with_flags. > > Signed-off-by: Alexandre Belloni > --- > drivers/pwm/core.c | 5 + > include/linux/pwm.h | 2 ++ > 2 files changed, 7 insertions(+) > > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c > index a80471399c20..206e5996359c 100644 > --- a/drivers/pwm/core.c > +++ b/drivers/pwm/core.c > @@ -663,6 +663,11 @@ struct pwm_device *pwm_get(struct device *dev, const > char *con_id) > > if (chip) > pwm = pwm_request_from_chip(chip, index, con_id ?: dev_id); > + if (IS_ERR(pwm)) > + return pwm; > + > + pwm_set_period(pwm, p->period); > + pwm_set_polarity(pwm, p->polarity); > > mutex_unlock(&pwm_lookup_lock); Clearly, this is not right. Returning while leaving the mutex locked? No. The second issue is... with _just_ this patch applied, we end up with "period" and "polarity" presumably initialised to zero, which means we now end up with the above explicitly setting the period and polarity as such. Isn't that going to change the behaviour of this? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe 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/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 11:01 PM, Stephen Warren wrote: Ok, the existing field is being replaced by something? I didn't get that No, not replaced. I'm adding the support for generic PHY to the existing USB PHY support. I thought that was clear from the changelog. from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable. OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1. What is the reason for all of this? That is, can you explain the difference between USB PHY support and general PHY support, and why we need both? The generic PHY framework (drivers/phy/phy-core.c) supports multifunction "complex" PHYs (some functions of which may be related to USB). My case is a Renesas R-Car generation 2 PHY that can switch two USB ports between different USB controllers (one PCI and one non-PCI on each port); I just haven't CCed linux-usb on my driver submission. Though there's already drivers/phy/usb/ driver for that hardware, it failed to meet the expectations (dynamic setting of the port multiplexing depending on what USB host/gadget drivers are loaded), so I had to write a new driver. I guess I don't need to describe drivers/phy/usb/ framework in detail, do I? It only provides for single-function "simple" USB PHYs... Naively, it sounds like the complex PHY driver should also be a pinctrl driver, since it sounds like the main feature it has beyond a simple PHY is the ability to do pin muxing. It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe 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/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 12:16 PM, Sergei Shtylyov wrote: > Hello. > > On 04/09/2014 09:56 PM, Alan Stern wrote: > Ok, the existing field is being replaced by something? I didn't get that > >>> No, not replaced. I'm adding the support for generic PHY to the >>> existing >>> USB PHY support. I thought that was clear from the changelog. > from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable. > >>> OK, I'll respin the patch #2 with 'gen_phy' and remove the patch >>> #1. > >> What is the reason for all of this? That is, can you explain the >> difference between USB PHY support and general PHY support, and why we >> need both? > >The generic PHY framework (drivers/phy/phy-core.c) supports > multifunction "complex" PHYs (some functions of which may be related to > USB). My case is a Renesas R-Car generation 2 PHY that can switch two > USB ports between different USB controllers (one PCI and one non-PCI on > each port); I just haven't CCed linux-usb on my driver submission. > Though there's already drivers/phy/usb/ driver for that hardware, it > failed to meet the expectations (dynamic setting of the port > multiplexing depending on what USB host/gadget drivers are loaded), so I > had to write a new driver. I guess I don't need to describe > drivers/phy/usb/ framework in detail, do I? It only provides for > single-function "simple" USB PHYs... Naively, it sounds like the complex PHY driver should also be a pinctrl driver, since it sounds like the main feature it has beyond a simple PHY is the ability to do pin muxing. -- To unsubscribe from this list: send the line "unsubscribe 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/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
Hello. On 04/09/2014 09:56 PM, Alan Stern wrote: Ok, the existing field is being replaced by something? I didn't get that No, not replaced. I'm adding the support for generic PHY to the existing USB PHY support. I thought that was clear from the changelog. from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable. OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1. What is the reason for all of this? That is, can you explain the difference between USB PHY support and general PHY support, and why we need both? The generic PHY framework (drivers/phy/phy-core.c) supports multifunction "complex" PHYs (some functions of which may be related to USB). My case is a Renesas R-Car generation 2 PHY that can switch two USB ports between different USB controllers (one PCI and one non-PCI on each port); I just haven't CCed linux-usb on my driver submission. Though there's already drivers/phy/usb/ driver for that hardware, it failed to meet the expectations (dynamic setting of the port multiplexing depending on what USB host/gadget drivers are loaded), so I had to write a new driver. I guess I don't need to describe drivers/phy/usb/ framework in detail, do I? It only provides for single-function "simple" USB PHYs... Alan Stern WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] improve pwm lookup support without device tree
Hi, a small patch set as suggested byt Thierry to make lokkup with the lookup table instead of device tree bahve more like when using device tree. The first patch adds a period annd a polarity member to the lookup table and use those to set period and polarity. The second patch changes PWM_LOOKUP to set period an polarity. I was wondering about adding a new macro to d that but the number of boards using it is limited (only 3) so I guess it is ok to do that now. The final goal would be to get rid of .pwm_period_ns in leds-pwm and pwm_bl. Alexandre Belloni (2): pwm: add period and polarity to struct pwm_lookup pwm: use PWM_LOOKUP to set the period and polarity Documentation/pwm.txt | 3 ++- arch/arm/mach-omap2/board-omap3beagle.c| 3 ++- arch/arm/mach-pxa/hx4700.c | 3 ++- arch/arm/mach-shmobile/board-armadillo800eva.c | 3 ++- drivers/pwm/core.c | 5 + include/linux/pwm.h| 6 +- 6 files changed, 18 insertions(+), 5 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] pwm: use PWM_LOOKUP to set the period and polarity
Now that the PWM core is able to set the period and polarity based on
the lookup table, add those to PWM_LOOKUP to ease their usage.
Signed-off-by: Alexandre Belloni
---
Documentation/pwm.txt | 3 ++-
arch/arm/mach-omap2/board-omap3beagle.c| 3 ++-
arch/arm/mach-pxa/hx4700.c | 3 ++-
arch/arm/mach-shmobile/board-armadillo800eva.c | 3 ++-
include/linux/pwm.h| 4 +++-
5 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 93cb97974986..f38f99cda64f 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -19,7 +19,8 @@ should instead register a static mapping that can be used to
match PWM
consumers to providers, as given in the following example:
static struct pwm_lookup board_pwm_lookup[] = {
- PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL),
+ PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL,
+ 5, PWM_POLARITY_NORMAL),
};
static void __init board_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index d6ed819ff15c..54c135a5b4f7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -61,7 +61,8 @@
static struct pwm_lookup pwm_lookup[] = {
/* LEDB -> PMU_STAT */
- PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat"),
+ PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat",
+ 7812500, PWM_POLARITY_NORMAL),
};
static struct led_pwm pwm_leds[] = {
diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index a7c30eb0c8db..c66ad4edc5e3 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -574,7 +574,8 @@ static struct platform_device backlight = {
};
static struct pwm_lookup hx4700_pwm_lookup[] = {
- PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL),
+ PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL,
+ 30923, PWM_POLARITY_NORMAL),
};
/*
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 2858f380beae..e2c4c5010f19 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -416,7 +416,8 @@ static struct platform_device pwm_device = {
};
static struct pwm_lookup pwm_lookup[] = {
- PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL),
+ PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL,
+ 3, PWM_POLARITY_NORMAL),
};
/* LCDC and backlight */
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 2f45e2fe5b93..e90628cac8fa 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -278,12 +278,14 @@ struct pwm_lookup {
enum pwm_polarity polarity;
};
-#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id)\
+#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id, _period, _polarity) \
{ \
.provider = _provider, \
.index = _index,\
.dev_id = _dev_id, \
.con_id = _con_id, \
+ .period = _period, \
+ .polarity = _polarity \
}
#if IS_ENABLED(CONFIG_PWM)
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] pwm: add period and polarity to struct pwm_lookup
Adds a period and a polarity member to struct pwm_lookup so that when performing
a lookup using the lookup table instead of device tree, we are able to set the
period and the polarity accordingly like what is done in
of_pwm_xlate_with_flags.
Signed-off-by: Alexandre Belloni
---
drivers/pwm/core.c | 5 +
include/linux/pwm.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index a80471399c20..206e5996359c 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -663,6 +663,11 @@ struct pwm_device *pwm_get(struct device *dev, const char
*con_id)
if (chip)
pwm = pwm_request_from_chip(chip, index, con_id ?: dev_id);
+ if (IS_ERR(pwm))
+ return pwm;
+
+ pwm_set_period(pwm, p->period);
+ pwm_set_polarity(pwm, p->polarity);
mutex_unlock(&pwm_lookup_lock);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 4717f54051cb..2f45e2fe5b93 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -274,6 +274,8 @@ struct pwm_lookup {
unsigned int index;
const char *dev_id;
const char *con_id;
+ unsigned int period;
+ enum pwm_polarity polarity;
};
#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id)\
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On Wed, 9 Apr 2014, Sergei Shtylyov wrote: > > Ok, the existing field is being replaced by something? I didn't get that > > No, not replaced. I'm adding the support for generic PHY to the existing > USB PHY support. I thought that was clear from the changelog. > > > from the patch description; I thought the new name in this patch was > > going to be it. In that case, a temporary name of usb_phy for the > > existing field, or adding the new field as gen_phy sound reasonable. > > OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1. What is the reason for all of this? That is, can you explain the difference between USB PHY support and general PHY support, and why we need both? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe 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/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 09:37 PM, Stephen Warren wrote: Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'. This is in preparation to adding the generic PHY support. Surely if the correct term is transceiver, we should be adding generic transceiver support not generic PHY support? To be honest, this rename feels like churn, especially since the APIs and DT bindings all still include the work phy so now everything will be inconsistent. How about 'usb_phy'? That certainly would make things more consistent, but I wonder why "usb_phy" is better than "phy" when the code/struct in question is something USB-specific; the "usb_" prefix seems implicit to me due to context. I tend to agree. However, I need to name the new field of stype 'struct phy *' somehow... perhaps something like 'gen_phy' for it would do? Ok, the existing field is being replaced by something? I didn't get that No, not replaced. I'm adding the support for generic PHY to the existing USB PHY support. I thought that was clear from the changelog. from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable. OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe 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/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 10:53 AM, Sergei Shtylyov wrote: > On 04/09/2014 08:48 PM, Stephen Warren wrote: > > Return to the 'phy' field of 'struct usb_hcd' its historic name > 'transceiver'. > This is in preparation to adding the generic PHY support. > Surely if the correct term is transceiver, we should be adding generic transceiver support not generic PHY support? To be honest, this rename feels like churn, especially since the APIs and DT bindings all still include the work phy so now everything will be inconsistent. > >>> How about 'usb_phy'? > >> That certainly would make things more consistent, but I wonder why >> "usb_phy" is better than "phy" when the code/struct in question is >> something USB-specific; the "usb_" prefix seems implicit to me due to >> context. > >I tend to agree. However, I need to name the new field of stype > 'struct phy *' somehow... perhaps something like 'gen_phy' for it would do? Ok, the existing field is being replaced by something? I didn't get that from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable. -- To unsubscribe from this list: send the line "unsubscribe 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/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 08:48 PM, Stephen Warren wrote: Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'. This is in preparation to adding the generic PHY support. Surely if the correct term is transceiver, we should be adding generic transceiver support not generic PHY support? To be honest, this rename feels like churn, especially since the APIs and DT bindings all still include the work phy so now everything will be inconsistent. How about 'usb_phy'? That certainly would make things more consistent, but I wonder why "usb_phy" is better than "phy" when the code/struct in question is something USB-specific; the "usb_" prefix seems implicit to me due to context. I tend to agree. However, I need to name the new field of stype 'struct phy *' somehow... perhaps something like 'gen_phy' for it would do? WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Wednesday 09 April 2014 12:33 PM, Russell King - ARM Linux wrote:
> On Tue, Apr 08, 2014 at 11:17:17AM -0400, Santosh Shilimkar wrote:
>> On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
>>> On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
> diff --git a/arch/arm/mach-omap2/omap4-common.c
> b/arch/arm/mach-omap2/omap4-common.c
> index f8b8dac..6b2a056 100644
> --- a/arch/arm/mach-omap2/omap4-common.c
> +++ b/arch/arm/mach-omap2/omap4-common.c
> @@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
>
> return omap_l2_cache_init(aux_ctrl, 0xc19f);
> }
> +
> +int __init am43xx_l2_cache_init(void)
> +{
> + u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
> +L310_AUX_CTRL_INSTR_PREFETCH;
It would be good to documenting the difference between this and OMAP4,
and why you have chosen different values.
>>>
>>> There are two main differences:
>>>
>>> 1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
>>> not needed even in OMAP4 with latest kernel, but I am not sure if I can
>>> do this safely without breaking any usecase currently working with OMAP4.
>>>
>> Wrong. Shared bit is mandatory for the OMAP4. Its a SMP system
>> which needs that.
>
> Errr. This bit affects the L2 cache behaviour for Normal memory, outer
> non-cacheable accesses - in other words, those performed to memory mapped
> via dma_alloc_coherent() or dma_alloc_writecombine(). It does not affect
> other types of mappings (other access types ignore the sharable attribute).
>
> When this bit is clear, accesses to such memory are:
>
> - read: cacheable, no allocate
> - write: write through, no write allocate
>
> what this means is that if there are no cache lines in the L2 cache
> corresponding with the physical address, then none will be allocated.
> However, if there are cache lines present, then they will be hit,
> read or updated as appropriate.
>
> This may matter before CMA where we had the memory returned by
> dma_alloc_coherent() and friends mapped as normal, cacheable mappings
> which could be speculatively prefetched, and therefore cache lines
> dragged into the L2 cache for these physical addresses.
>
> However, now that we're using CMA, this does not apply as we no longer
> have this aliasing mapping.
>
> So, with CMA enabled, it should be safe not to set this bit.
>
Agree. That should be safe now.
> However, the shared bit in the page tables must be set for SMP systems.
> Are you sure you're not confusing the shared bit in the page tables
> with the shared override bit in the L2 cache controller?
>
No i didn't confuse with page table bits. But the SMP remark wasn't
relevant which might have indicated that.
>>> 2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
>>> searched through the commit history of L2 cache support on OMAP4 but
>>> there is no mention of why this was needed on OMAP4. I am checking
>>> internally on the history behind this.
>>>
>> These have also come from the aligned settings with hardware folks.
>
> Again, this doesn't have much to do with hardware, it's secure/non-secure
> access rights configuration to the L2 cache controller.
>
The settings were aligned by hardware team after consulting security
team and those couple of bit settings came from them. The folks
are no longer working for TI so I can't go back and check the reasons.
We just just leave them as is.
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/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 10:27 AM, Sergei Shtylyov wrote: > Hello. > > On 04/09/2014 07:31 PM, Stephen Warren wrote: > >>> Return to the 'phy' field of 'struct usb_hcd' its historic name >>> 'transceiver'. >>> This is in preparation to adding the generic PHY support. > >> Surely if the correct term is transceiver, we should be adding generic >> transceiver support not generic PHY support? To be honest, this rename >> feels like churn, especially since the APIs and DT bindings all still >> include the work phy so now everything will be inconsistent. > >How about 'usb_phy'? That certainly would make things more consistent, but I wonder why "usb_phy" is better than "phy" when the code/struct in question is something USB-specific; the "usb_" prefix seems implicit to me due to context. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Tue, Apr 08, 2014 at 11:17:17AM -0400, Santosh Shilimkar wrote:
> On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
> > On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
> >> On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
> >>> diff --git a/arch/arm/mach-omap2/omap4-common.c
> >>> b/arch/arm/mach-omap2/omap4-common.c
> >>> index f8b8dac..6b2a056 100644
> >>> --- a/arch/arm/mach-omap2/omap4-common.c
> >>> +++ b/arch/arm/mach-omap2/omap4-common.c
> >>> @@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
> >>>
> >>> return omap_l2_cache_init(aux_ctrl, 0xc19f);
> >>> }
> >>> +
> >>> +int __init am43xx_l2_cache_init(void)
> >>> +{
> >>> + u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
> >>> +L310_AUX_CTRL_INSTR_PREFETCH;
> >>
> >> It would be good to documenting the difference between this and OMAP4,
> >> and why you have chosen different values.
> >
> > There are two main differences:
> >
> > 1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
> > not needed even in OMAP4 with latest kernel, but I am not sure if I can
> > do this safely without breaking any usecase currently working with OMAP4.
> >
> Wrong. Shared bit is mandatory for the OMAP4. Its a SMP system
> which needs that.
Errr. This bit affects the L2 cache behaviour for Normal memory, outer
non-cacheable accesses - in other words, those performed to memory mapped
via dma_alloc_coherent() or dma_alloc_writecombine(). It does not affect
other types of mappings (other access types ignore the sharable attribute).
When this bit is clear, accesses to such memory are:
- read: cacheable, no allocate
- write: write through, no write allocate
what this means is that if there are no cache lines in the L2 cache
corresponding with the physical address, then none will be allocated.
However, if there are cache lines present, then they will be hit,
read or updated as appropriate.
This may matter before CMA where we had the memory returned by
dma_alloc_coherent() and friends mapped as normal, cacheable mappings
which could be speculatively prefetched, and therefore cache lines
dragged into the L2 cache for these physical addresses.
However, now that we're using CMA, this does not apply as we no longer
have this aliasing mapping.
So, with CMA enabled, it should be safe not to set this bit.
However, the shared bit in the page tables must be set for SMP systems.
Are you sure you're not confusing the shared bit in the page tables
with the shared override bit in the L2 cache controller?
> > 2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
> > searched through the commit history of L2 cache support on OMAP4 but
> > there is no mention of why this was needed on OMAP4. I am checking
> > internally on the history behind this.
> >
> These have also come from the aligned settings with hardware folks.
Again, this doesn't have much to do with hardware, it's secure/non-secure
access rights configuration to the L2 cache controller.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe 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/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
Hello. On 04/09/2014 07:31 PM, Stephen Warren wrote: Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'. This is in preparation to adding the generic PHY support. Surely if the correct term is transceiver, we should be adding generic transceiver support not generic PHY support? To be honest, this rename feels like churn, especially since the APIs and DT bindings all still include the work phy so now everything will be inconsistent. How about 'usb_phy'? WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Tue, Apr 08, 2014 at 08:23:39PM +0530, Sekhar Nori wrote:
> On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
> > On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
> >> diff --git a/arch/arm/mach-omap2/omap4-common.c
> >> b/arch/arm/mach-omap2/omap4-common.c
> >> index f8b8dac..6b2a056 100644
> >> --- a/arch/arm/mach-omap2/omap4-common.c
> >> +++ b/arch/arm/mach-omap2/omap4-common.c
> >> @@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
> >>
> >>return omap_l2_cache_init(aux_ctrl, 0xc19f);
> >> }
> >> +
> >> +int __init am43xx_l2_cache_init(void)
> >> +{
> >> + u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
> >> + L310_AUX_CTRL_INSTR_PREFETCH;
> >
> > It would be good to documenting the difference between this and OMAP4,
> > and why you have chosen different values.
>
> There are two main differences:
>
> 1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
> not needed even in OMAP4 with latest kernel, but I am not sure if I can
> do this safely without breaking any usecase currently working with OMAP4.
>
> 2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
> searched through the commit history of L2 cache support on OMAP4 but
> there is no mention of why this was needed on OMAP4. I am checking
> internally on the history behind this.
That is required because as part of the enable sequence, we write to the
lockdown registers to clear out anything that may be there before we
enable the L2 cache. If we didn't set the NS lockdown bit, then we
would need the secure monitor to do it for us.
The NS interrupt access bit is also a good idea to be set, since this
allows us to eventually support EDAC with PL310. As we don't support
EDAC at the moment, or touch the interrupt registers, we can probably
ignore this difference and just preserve whatever value is there for
the time being.
Both of these bits should be managed within the L2C code rather than by
platforms.
> 3) OMAP4 sets cache replacement policy to RR which is not a big deal
> since thats the default anyway. We can probably drop this setting even
> from OMAP4.
Yes, since that would just be a case of preserving that bit.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe 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/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 07:57 AM, Sergei Shtylyov wrote: > Return to the 'phy' field of 'struct usb_hcd' its historic name > 'transceiver'. > This is in preparation to adding the generic PHY support. Surely if the correct term is transceiver, we should be adding generic transceiver support not generic PHY support? To be honest, this rename feels like churn, especially since the APIs and DT bindings all still include the work phy so now everything will be inconsistent. -- To unsubscribe from this list: send the line "unsubscribe 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: OMAP3: hwmod_data: Correct clock domains for USB modules
On 04/09/2014 10:16 AM, Roger Quadros wrote:
> OMAP3 doesn't contain "l3_init_clkdm" clock domain. Use the
> proper clock domains for USB Host and USB TLL modules.
>
> Gets rid of the following warnings during boot
> omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
> omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
>
> Reported-by: Nishant Menon
I guess I have a "h" at the end of my first name :P
> CC: Paul Walmsley
> Signed-off-by: Roger Quadros
> ---
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 9c7e23a..3aa49ed 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -1968,7 +1968,7 @@ static struct omap_hwmod_irq_info
> omap3xxx_usb_host_hs_irqs[] = {
> static struct omap_hwmod omap3xxx_usb_host_hs_hwmod = {
> .name = "usb_host_hs",
> .class = &omap3xxx_usb_host_hs_hwmod_class,
> - .clkdm_name = "l3_init_clkdm",
> + .clkdm_name = "usbhost_clkdm",
> .mpu_irqs = omap3xxx_usb_host_hs_irqs,
> .main_clk = "usbhost_48m_fck",
> .prcm = {
> @@ -2053,7 +2053,7 @@ static struct omap_hwmod_irq_info
> omap3xxx_usb_tll_hs_irqs[] = {
> static struct omap_hwmod omap3xxx_usb_tll_hs_hwmod = {
> .name = "usb_tll_hs",
> .class = &omap3xxx_usb_tll_hs_hwmod_class,
> - .clkdm_name = "l3_init_clkdm",
> + .clkdm_name = "core_l4_clkdm",
> .mpu_irqs = omap3xxx_usb_tll_hs_irqs,
> .main_clk = "usbtll_fck",
> .prcm = {
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP3: hwmod_data: Correct clock domains for USB modules
OMAP3 doesn't contain "l3_init_clkdm" clock domain. Use the
proper clock domains for USB Host and USB TLL modules.
Gets rid of the following warnings during boot
omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
Reported-by: Nishant Menon
CC: Paul Walmsley
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9c7e23a..3aa49ed 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1968,7 +1968,7 @@ static struct omap_hwmod_irq_info
omap3xxx_usb_host_hs_irqs[] = {
static struct omap_hwmod omap3xxx_usb_host_hs_hwmod = {
.name = "usb_host_hs",
.class = &omap3xxx_usb_host_hs_hwmod_class,
- .clkdm_name = "l3_init_clkdm",
+ .clkdm_name = "usbhost_clkdm",
.mpu_irqs = omap3xxx_usb_host_hs_irqs,
.main_clk = "usbhost_48m_fck",
.prcm = {
@@ -2053,7 +2053,7 @@ static struct omap_hwmod_irq_info
omap3xxx_usb_tll_hs_irqs[] = {
static struct omap_hwmod omap3xxx_usb_tll_hs_hwmod = {
.name = "usb_tll_hs",
.class = &omap3xxx_usb_tll_hs_hwmod_class,
- .clkdm_name = "l3_init_clkdm",
+ .clkdm_name = "core_l4_clkdm",
.mpu_irqs = omap3xxx_usb_tll_hs_irqs,
.main_clk = "usbtll_fck",
.prcm = {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
On Tue, Apr 08, 2014 at 05:02:37PM +0200, Laurent Pinchart wrote: > On Tuesday 08 April 2014 15:43:22 Joerg Roedel wrote: > > Who is "someone" in this case? > > That's exactly the problem :-) The ARM DMA API implementation doesn't care > who > that "someone" is. Existing implementations call those functions either from > the bus masters device drivers (in which case the drivers need to be IOMMU- > aware, even if they use the DMA API and don't need to handle the IOMMU > directly) or from the IOMMU drivers (in which case the bus masters device > drivers don't have to care about the IOMMU, but without a way for drivers to > handle the IOMMU directly when they need to). Possible other candidates are > core IOMMU code or bus code. That doesn't sound very transparent for the device drivers. All what you describe above (attaching a device to its default domain for DMA-API) should happen in the IOMMU driver. For the device driver it should make no difference if there is an IOMMU or not. > If we call arm_iommu_attach_device() from the IOMMU driver to get default > transparent IOMMU handling, the function will then attach the device to the > default domain with a call to iommu_attach_device(). If you have to call a function it is not transparent anymore. > If a driver needs to handle the IOMMU directly, should it start by > detaching the device from the ARM IOMMU domain ? We would need to be > very careful with the assumptions made by the different layers, as > they might not support a driver attaching a new domain to a device > that already has a domain attached. I'd feel more comfortable with > avoiding to attach the default domain to the device in the first > place, but that might not be easily doable. The way this is solved by others is that iommu_attach_device() automatically detaches the device from its default (DMA-API) domain and attach it to the device drivers own domain. On iommu_detach_device() the device is attached back to the default domain. Joerg -- To unsubscribe from this list: send the line "unsubscribe 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] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'.
This is in preparation to adding the generic PHY support.
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
drivers/usb/chipidea/host.c |2 +-
drivers/usb/core/hcd.c| 20 ++--
drivers/usb/core/hub.c|9 +
drivers/usb/host/ehci-fsl.c | 16
drivers/usb/host/ehci-hub.c |2 +-
drivers/usb/host/ehci-msm.c |4 ++--
drivers/usb/host/ehci-tegra.c | 16
drivers/usb/host/ohci-omap.c | 20 ++--
include/linux/usb/hcd.h |6 +++---
9 files changed, 48 insertions(+), 47 deletions(-)
Index: usb/drivers/usb/chipidea/host.c
===
--- usb.orig/drivers/usb/chipidea/host.c
+++ usb/drivers/usb/chipidea/host.c
@@ -59,7 +59,7 @@ static int host_start(struct ci_hdrc *ci
hcd->has_tt = 1;
hcd->power_budget = ci->platdata->power_budget;
- hcd->phy = ci->transceiver;
+ hcd->transceiver = ci->transceiver;
ehci = hcd_to_ehci(hcd);
ehci->caps = ci->hw_bank.cap;
Index: usb/drivers/usb/core/hcd.c
===
--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -2605,7 +2605,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
- if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->phy) {
+ if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->transceiver) {
struct usb_phy *phy = usb_get_phy_dev(hcd->self.controller, 0);
if (IS_ERR(phy)) {
@@ -2618,7 +2618,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_put_phy(phy);
return retval;
}
- hcd->phy = phy;
+ hcd->transceiver = phy;
hcd->remove_phy = 1;
}
}
@@ -2764,10 +2764,10 @@ err_allocate_root_hub:
err_register_bus:
hcd_buffer_destroy(hcd);
err_remove_phy:
- if (hcd->remove_phy && hcd->phy) {
- usb_phy_shutdown(hcd->phy);
- usb_put_phy(hcd->phy);
- hcd->phy = NULL;
+ if (hcd->remove_phy && hcd->transceiver) {
+ usb_phy_shutdown(hcd->transceiver);
+ usb_put_phy(hcd->transceiver);
+ hcd->transceiver = NULL;
}
return retval;
}
@@ -2841,10 +2841,10 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_put_dev(hcd->self.root_hub);
usb_deregister_bus(&hcd->self);
hcd_buffer_destroy(hcd);
- if (hcd->remove_phy && hcd->phy) {
- usb_phy_shutdown(hcd->phy);
- usb_put_phy(hcd->phy);
- hcd->phy = NULL;
+ if (hcd->remove_phy && hcd->transceiver) {
+ usb_phy_shutdown(hcd->transceiver);
+ usb_put_phy(hcd->transceiver);
+ hcd->transceiver = NULL;
}
}
EXPORT_SYMBOL_GPL(usb_remove_hcd);
Index: usb/drivers/usb/core/hub.c
===
--- usb.orig/drivers/usb/core/hub.c
+++ usb/drivers/usb/core/hub.c
@@ -4250,8 +4250,8 @@ hub_port_init (struct usb_hub *hub, stru
if (retval)
goto fail;
- if (hcd->phy && !hdev->parent)
- usb_phy_notify_connect(hcd->phy, udev->speed);
+ if (hcd->transceiver && !hdev->parent)
+ usb_phy_notify_connect(hcd->transceiver, udev->speed);
/*
* Some superspeed devices have finished the link training process
@@ -4459,9 +4459,10 @@ static void hub_port_connect_change(stru
/* Disconnect any existing devices under this port */
if (udev) {
- if (hcd->phy && !hdev->parent &&
+ if (hcd->transceiver && !hdev->parent &&
!(portstatus & USB_PORT_STAT_CONNECTION))
- usb_phy_notify_disconnect(hcd->phy, udev->speed);
+ usb_phy_notify_disconnect(hcd->transceiver,
+ udev->speed);
usb_disconnect(&hub->ports[port1 - 1]->child);
}
clear_bit(port1, hub->change_bits);
Index: usb/drivers/usb/host/ehci-fsl.c
===
--- usb.orig/drivers/usb/host/ehci-fsl.c
+++ usb/drivers/usb/host/ehci-fsl.c
@@ -136,15 +136,15 @@ static int usb_hcd_fsl_probe(const struc
if (pdata->operating_mode == FSL_USB2_DR_OTG) {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- hcd->phy = usb_get_phy(USB_PHY_TYPE_USB2);
+ hcd->transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
dev_dbg(&pdev->dev, "hcd=0x%p ehci=0x%p, phy=0x%p\n",
- hcd,
Re: omap based boards (next-20140409-omap2plus_defconfig) - boot time warning:
Nishant, On 04/09/2014 04:15 PM, Nishanth Menon wrote: > On 04/09/2014 07:41 AM, Nishanth Menon wrote: >> Hi, >> http://slexy.org/raw/s2pkLsiFBX >> >> I noticed the following sets of warnings with omap2plus_defconfig on >> next-20140409. As per older logs, next-20140401 had it and v3.14 tag >> also had it (I have'nt retained older logs). >> > > Here is a quick list of 20 odd boards I am testing with: > > next-20140409-omap2plus_defconfig > > 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Ho7WPbaZ > omap_hwmod: tptc* using broken dt data from edma > platform 4900.edma: alias fck already exists > > 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2A5ZJjsuZ > same for tptc, edma > > 3: am3517-evm: Boot PASS: http://slexy.org/raw/s20q8rTwCJ > omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp > omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm > Address Hole seen by USB_OTG at address dc0f9c0c > platform iva.2: Cannot lookup hwmod 'iva' > platform 480c5000.aes: Cannot lookup hwmod 'aes' > platform 48094000.mailbox: Cannot lookup hwmod 'mailbox' > platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp' > platform 480c3000.sham: Cannot lookup hwmod 'sham' > platform 480cb000.smartreflex: Cannot lookup hwmod 'smartreflex_core' > platform 480cb000.smartreflex: Cannot lookup hwmod 'smartreflex_iva' > edma-dma-engine: probe of edma-dma-engine.0 failed with error -5 > > 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21kcHKdyf > nothing interesting. > > 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s210geZKgS > platform 53701000.des: Cannot lookup hwmod 'des' > platform 4900.edma: alias fck already exists > the usb and qspi issue reported. > > 6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s20t5JOyI4 > known issue. (gpio reset for DDR) > > 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2TXdBONNI > omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp > omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp > omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm > omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm these 2 usb host/tll messages seem to appear for all OMAP3 based boards. Seems like incorrect hwmod data. I'll send a patch to fix this. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap based boards (next-20140409-omap2plus_defconfig) - boot time warning:
On 04/09/2014 07:41 AM, Nishanth Menon wrote: > Hi, > http://slexy.org/raw/s2pkLsiFBX > > I noticed the following sets of warnings with omap2plus_defconfig on > next-20140409. As per older logs, next-20140401 had it and v3.14 tag > also had it (I have'nt retained older logs). > Here is a quick list of 20 odd boards I am testing with: next-20140409-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Ho7WPbaZ omap_hwmod: tptc* using broken dt data from edma platform 4900.edma: alias fck already exists 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2A5ZJjsuZ same for tptc, edma 3: am3517-evm: Boot PASS: http://slexy.org/raw/s20q8rTwCJ omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm Address Hole seen by USB_OTG at address dc0f9c0c platform iva.2: Cannot lookup hwmod 'iva' platform 480c5000.aes: Cannot lookup hwmod 'aes' platform 48094000.mailbox: Cannot lookup hwmod 'mailbox' platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp' platform 480c3000.sham: Cannot lookup hwmod 'sham' platform 480cb000.smartreflex: Cannot lookup hwmod 'smartreflex_core' platform 480cb000.smartreflex: Cannot lookup hwmod 'smartreflex_iva' edma-dma-engine: probe of edma-dma-engine.0 failed with error -5 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21kcHKdyf nothing interesting. 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s210geZKgS platform 53701000.des: Cannot lookup hwmod 'des' platform 4900.edma: alias fck already exists the usb and qspi issue reported. 6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s20t5JOyI4 known issue. (gpio reset for DDR) 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2TXdBONNI omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm edma-dma-engine: probe of edma-dma-engine.0 failed with error -5 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s24pDuZ7S7 omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp omap_hwmod: ssi: doesn't have mpu register target base omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm omap_hwmod: mcbsp2: cannot be enabled for reset (3) edma-dma-engine: probe of edma-dma-engine.0 failed with error -5 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s21ztl1meX omap_hwmod: tptc0 using broken dt data from edma omap_hwmod: tptc1 using broken dt data from edma omap_hwmod: tptc2 using broken dt data from edma omap_hwmod: debugss: _wait_target_disable failed platform 4900.edma: alias fck already exists platform 4900.edma: alias fck already exists platform 4900.edma: alias fck already exists 10: beaglebone: Boot PASS: http://slexy.org/raw/s2a2JO9MVd omap_hwmod: tptc0 using broken dt data from edma omap_hwmod: tptc1 using broken dt data from edma omap_hwmod: tptc2 using broken dt data from edma omap_hwmod: debugss: _wait_target_disable failed platform 4900.edma: alias fck already exists platform 4900.edma: alias fck already exists platform 4900.edma: alias fck already exists 11: craneboard: Boot PASS: http://slexy.org/raw/s20xtW58E3 Address Hole seen by USB_OTG at address 4de96fbc omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm omap_hwmod: uart4: cannot be enabled for reset (3) platform iva.2: Cannot lookup hwmod 'iva' platform 480c5000.aes: Cannot lookup hwmod 'aes' platform 48094000.mailbox: Cannot lookup hwmod 'mailbox' platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp' platform 480c3000.sham: Cannot lookup hwmod 'sham' platform 480cb000.smartreflex: Cannot lookup hwmod 'smartreflex_core' platform 480c9000.smartreflex: Cannot lookup hwmod 'smartreflex_mpu_iva' platform 480ab000.usb_otg_hs: Cannot lookup hwmod 'usb_otg_hs' edma-dma-engine: probe of edma-dma-engine.0 failed with error -5 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2TR2UyTxS omap_hwmod: l3_main_2 using broken dt data from ocp omap_hwmod: dss_core: _wait_target_disable failed omap_hwmod: dss_core: cannot be enabled for reset (3) omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_hdmi: cannot be enabled for reset (3) platform 4e00.dmm: Cannot lookup hwmod 'dmm' omap_l3_noc 4400.ocp: couldn't find resource 2 edma-dma-engine: probe of edma-dma-engine.
Re: AM437x-epos (next-20140409-omap2plus_defconfig) - boot time warning: qspi/otg..
Hi Nishanth, The dts date were posted but due to some functional changes going in spi core, the dts data were not picked(predictiong some changes in dt parameters). I will send a minimal qspi node during rc cycle to get rid of this warning. On Wednesday 09 April 2014 06:20 PM, Roger Quadros wrote: +George Hi Nishant, I remember George had sent patches to add USB DT nodes for am43xx. Looks like they didn't get through. Adding the USB nodes should get rid of the warning. George, Can you please resend a minimal set to fix this warning for -rc? Thanks. cheers, -roger On 04/09/2014 03:41 PM, Nishanth Menon wrote: Hi, http://slexy.org/raw/s2pkLsiFBX I noticed the following sets of warnings with omap2plus_defconfig on next-20140409. As per older logs, next-20140401 had it and v3.14 tag also had it (I have'nt retained older logs). [0.226189] [ cut here ] [0.226258] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3e0() [0.226277] omap_hwmod: qspi: doesn't have mpu register target base [0.226290] Modules linked in: [0.226317] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-next-20140409-6-g0fbfc2e #1 [0.226389] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [0.226441] [] (show_stack) from [] (dump_stack+0x78/0x94) [0.226478] [] (dump_stack) from [] (warn_slowpath_common+0x6c/0x8c) [0.226504] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [0.226535] [] (warn_slowpath_fmt) from [] (_init+0x1c0/0x3e0) [0.226569] [] (_init) from [] (omap_hwmod_for_each+0x34/0x5c) [0.226598] [] (omap_hwmod_for_each) from [] (__omap_hwmod_setup_all+0x24/0x40) [0.226624] [] (__omap_hwmod_setup_all) from [] (do_one_initcall+0x34/0x15c) [0.226659] [] (do_one_initcall) from [] (kernel_init_freeable+0xfc/0x1cc) [0.226687] [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) [0.226721] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) [0.226930] ---[ end trace 6ef0f5570cfcc358 ]--- [0.264599] omap_hwmod: tptc0 using broken dt data from edma [0.265247] omap_hwmod: tptc1 using broken dt data from edma [0.265871] omap_hwmod: tptc2 using broken dt data from edma [0.274961] [ cut here ] [0.275029] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3e0() [0.275048] omap_hwmod: usb_otg_ss0: doesn't have mpu register target base [0.275058] Modules linked in: [0.275087] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 3.14.0-next-20140409-6-g0fbfc2e #1 [0.275158] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [0.275209] [] (show_stack) from [] (dump_stack+0x78/0x94) [0.275248] [] (dump_stack) from [] (warn_slowpath_common+0x6c/0x8c) [0.275274] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [0.275307] [] (warn_slowpath_fmt) from [] (_init+0x1c0/0x3e0) [0.275344] [] (_init) from [] (omap_hwmod_for_each+0x34/0x5c) [0.275376] [] (omap_hwmod_for_each) from [] (__omap_hwmod_setup_all+0x24/0x40) [0.275405] [] (__omap_hwmod_setup_all) from [] (do_one_initcall+0x34/0x15c) [0.275440] [] (do_one_initcall) from [] (kernel_init_freeable+0xfc/0x1cc) [0.275468] [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) [0.275501] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) [0.275517] ---[ end trace 6ef0f5570cfcc359 ]--- [0.276726] [ cut here ] [0.276777] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3e0() [0.276791] omap_hwmod: usb_otg_ss1: doesn't have mpu register target base [0.276802] Modules linked in: [0.276826] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 3.14.0-next-20140409-6-g0fbfc2e #1 [0.276891] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [0.276938] [] (show_stack) from [] (dump_stack+0x78/0x94) [0.276974] [] (dump_stack) from [] (warn_slowpath_common+0x6c/0x8c) [0.276999] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [0.277030] [] (warn_slowpath_fmt) from [] (_init+0x1c0/0x3e0) [0.277064] [] (_init) from [] (omap_hwmod_for_each+0x34/0x5c) [0.277095] [] (omap_hwmod_for_each) from [] (__omap_hwmod_setup_all+0x24/0x40) [0.277121] [] (__omap_hwmod_setup_all) from [] (do_one_initcall+0x34/0x15c) [0.277158] [] (do_one_initcall) from [] (kernel_init_freeable+0xfc/0x1cc) [0.277186] [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) [0.277219] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) [0.277234] ---[ end trace 6ef0f5570cfcc35a ]--- -- To unsubscribe from this list: send the line "unsubscribe 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: AM437x-epos (next-20140409-omap2plus_defconfig) - boot time warning: qspi/otg..
+George Hi Nishant, I remember George had sent patches to add USB DT nodes for am43xx. Looks like they didn't get through. Adding the USB nodes should get rid of the warning. George, Can you please resend a minimal set to fix this warning for -rc? Thanks. cheers, -roger On 04/09/2014 03:41 PM, Nishanth Menon wrote: > Hi, > http://slexy.org/raw/s2pkLsiFBX > > I noticed the following sets of warnings with omap2plus_defconfig on > next-20140409. As per older logs, next-20140401 had it and v3.14 tag > also had it (I have'nt retained older logs). > > [0.226189] [ cut here ] > [0.226258] WARNING: CPU: 0 PID: 1 at > arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3e0() > [0.226277] omap_hwmod: qspi: doesn't have mpu register target base > [0.226290] Modules linked in: > [0.226317] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 3.14.0-next-20140409-6-g0fbfc2e #1 > [0.226389] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [0.226441] [] (show_stack) from [] > (dump_stack+0x78/0x94) > [0.226478] [] (dump_stack) from [] > (warn_slowpath_common+0x6c/0x8c) > [0.226504] [] (warn_slowpath_common) from [] > (warn_slowpath_fmt+0x30/0x40) > [0.226535] [] (warn_slowpath_fmt) from [] > (_init+0x1c0/0x3e0) > [0.226569] [] (_init) from [] > (omap_hwmod_for_each+0x34/0x5c) > [0.226598] [] (omap_hwmod_for_each) from [] > (__omap_hwmod_setup_all+0x24/0x40) > [0.226624] [] (__omap_hwmod_setup_all) from > [] (do_one_initcall+0x34/0x15c) > [0.226659] [] (do_one_initcall) from [] > (kernel_init_freeable+0xfc/0x1cc) > [0.226687] [] (kernel_init_freeable) from [] > (kernel_init+0x8/0xe4) > [0.226721] [] (kernel_init) from [] > (ret_from_fork+0x14/0x2c) > [0.226930] ---[ end trace 6ef0f5570cfcc358 ]--- > [0.264599] omap_hwmod: tptc0 using broken dt data from edma > [0.265247] omap_hwmod: tptc1 using broken dt data from edma > [0.265871] omap_hwmod: tptc2 using broken dt data from edma > [0.274961] [ cut here ] > [0.275029] WARNING: CPU: 0 PID: 1 at > arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3e0() > [0.275048] omap_hwmod: usb_otg_ss0: doesn't have mpu register > target base > [0.275058] Modules linked in: > [0.275087] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW > 3.14.0-next-20140409-6-g0fbfc2e #1 > [0.275158] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [0.275209] [] (show_stack) from [] > (dump_stack+0x78/0x94) > [0.275248] [] (dump_stack) from [] > (warn_slowpath_common+0x6c/0x8c) > [0.275274] [] (warn_slowpath_common) from [] > (warn_slowpath_fmt+0x30/0x40) > [0.275307] [] (warn_slowpath_fmt) from [] > (_init+0x1c0/0x3e0) > [0.275344] [] (_init) from [] > (omap_hwmod_for_each+0x34/0x5c) > [0.275376] [] (omap_hwmod_for_each) from [] > (__omap_hwmod_setup_all+0x24/0x40) > [0.275405] [] (__omap_hwmod_setup_all) from > [] (do_one_initcall+0x34/0x15c) > [0.275440] [] (do_one_initcall) from [] > (kernel_init_freeable+0xfc/0x1cc) > [0.275468] [] (kernel_init_freeable) from [] > (kernel_init+0x8/0xe4) > [0.275501] [] (kernel_init) from [] > (ret_from_fork+0x14/0x2c) > [0.275517] ---[ end trace 6ef0f5570cfcc359 ]--- > [0.276726] [ cut here ] > [0.276777] WARNING: CPU: 0 PID: 1 at > arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3e0() > [0.276791] omap_hwmod: usb_otg_ss1: doesn't have mpu register > target base > [0.276802] Modules linked in: > [0.276826] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW > 3.14.0-next-20140409-6-g0fbfc2e #1 > [0.276891] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [0.276938] [] (show_stack) from [] > (dump_stack+0x78/0x94) > [0.276974] [] (dump_stack) from [] > (warn_slowpath_common+0x6c/0x8c) > [0.276999] [] (warn_slowpath_common) from [] > (warn_slowpath_fmt+0x30/0x40) > [0.277030] [] (warn_slowpath_fmt) from [] > (_init+0x1c0/0x3e0) > [0.277064] [] (_init) from [] > (omap_hwmod_for_each+0x34/0x5c) > [0.277095] [] (omap_hwmod_for_each) from [] > (__omap_hwmod_setup_all+0x24/0x40) > [0.277121] [] (__omap_hwmod_setup_all) from > [] (do_one_initcall+0x34/0x15c) > [0.277158] [] (do_one_initcall) from [] > (kernel_init_freeable+0xfc/0x1cc) > [0.277186] [] (kernel_init_freeable) from [] > (kernel_init+0x8/0xe4) > [0.277219] [] (kernel_init) from [] > (ret_from_fork+0x14/0x2c) > [0.277234] ---[ end trace 6ef0f5570cfcc35a ]--- > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AM437x-epos (next-20140409-omap2plus_defconfig) - boot time warning: qspi/otg..
Hi, http://slexy.org/raw/s2pkLsiFBX I noticed the following sets of warnings with omap2plus_defconfig on next-20140409. As per older logs, next-20140401 had it and v3.14 tag also had it (I have'nt retained older logs). [0.226189] [ cut here ] [0.226258] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3e0() [0.226277] omap_hwmod: qspi: doesn't have mpu register target base [0.226290] Modules linked in: [0.226317] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-next-20140409-6-g0fbfc2e #1 [0.226389] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [0.226441] [] (show_stack) from [] (dump_stack+0x78/0x94) [0.226478] [] (dump_stack) from [] (warn_slowpath_common+0x6c/0x8c) [0.226504] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [0.226535] [] (warn_slowpath_fmt) from [] (_init+0x1c0/0x3e0) [0.226569] [] (_init) from [] (omap_hwmod_for_each+0x34/0x5c) [0.226598] [] (omap_hwmod_for_each) from [] (__omap_hwmod_setup_all+0x24/0x40) [0.226624] [] (__omap_hwmod_setup_all) from [] (do_one_initcall+0x34/0x15c) [0.226659] [] (do_one_initcall) from [] (kernel_init_freeable+0xfc/0x1cc) [0.226687] [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) [0.226721] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) [0.226930] ---[ end trace 6ef0f5570cfcc358 ]--- [0.264599] omap_hwmod: tptc0 using broken dt data from edma [0.265247] omap_hwmod: tptc1 using broken dt data from edma [0.265871] omap_hwmod: tptc2 using broken dt data from edma [0.274961] [ cut here ] [0.275029] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3e0() [0.275048] omap_hwmod: usb_otg_ss0: doesn't have mpu register target base [0.275058] Modules linked in: [0.275087] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 3.14.0-next-20140409-6-g0fbfc2e #1 [0.275158] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [0.275209] [] (show_stack) from [] (dump_stack+0x78/0x94) [0.275248] [] (dump_stack) from [] (warn_slowpath_common+0x6c/0x8c) [0.275274] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [0.275307] [] (warn_slowpath_fmt) from [] (_init+0x1c0/0x3e0) [0.275344] [] (_init) from [] (omap_hwmod_for_each+0x34/0x5c) [0.275376] [] (omap_hwmod_for_each) from [] (__omap_hwmod_setup_all+0x24/0x40) [0.275405] [] (__omap_hwmod_setup_all) from [] (do_one_initcall+0x34/0x15c) [0.275440] [] (do_one_initcall) from [] (kernel_init_freeable+0xfc/0x1cc) [0.275468] [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) [0.275501] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) [0.275517] ---[ end trace 6ef0f5570cfcc359 ]--- [0.276726] [ cut here ] [0.276777] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3e0() [0.276791] omap_hwmod: usb_otg_ss1: doesn't have mpu register target base [0.276802] Modules linked in: [0.276826] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 3.14.0-next-20140409-6-g0fbfc2e #1 [0.276891] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [0.276938] [] (show_stack) from [] (dump_stack+0x78/0x94) [0.276974] [] (dump_stack) from [] (warn_slowpath_common+0x6c/0x8c) [0.276999] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [0.277030] [] (warn_slowpath_fmt) from [] (_init+0x1c0/0x3e0) [0.277064] [] (_init) from [] (omap_hwmod_for_each+0x34/0x5c) [0.277095] [] (omap_hwmod_for_each) from [] (__omap_hwmod_setup_all+0x24/0x40) [0.277121] [] (__omap_hwmod_setup_all) from [] (do_one_initcall+0x34/0x15c) [0.277158] [] (do_one_initcall) from [] (kernel_init_freeable+0xfc/0x1cc) [0.277186] [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) [0.277219] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) [0.277234] ---[ end trace 6ef0f5570cfcc35a ]--- -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv2] i2c: omap: Disable default probing of i2c devices for omap i2c.
On Wed, Apr 09, 2014 at 04:06:48PM +0530, Sourav Poddar wrote: > I2c core supports defualt probing functionality for devices not registered > through > dt/board files. If there are any client driver registered, i2c core will try > to > check if there is any device present corresponding to the address supplied by > the client driver. If the device is actually present and not registered, core > will register it, else the device default probe will fail and we get a omap > i2c controller > specific timeout messages. > For example, Using multi_v7_config on omap5-uevm, CONFIG_SENSORS_LM90 and > CONFIG_ICS932S401 > is the driver which is enabled and gets registered. I2c core tries to find a > valid > corresponding device on each of the address supplied by registered driver, > but could not find anyone. Hence, keep dumping the controller timeout speciic > message. This is exactly why I2C_CLASS_DEPRECATED was implemented. So, users which are using classes can migrate away. But this needs time. Given that I2C_CLASS_DEPRECATED is new in 3.15, I'd think setting classes to 0 (thus totally disabling them) should not be before 3.17. You don't need to resend, I'll do it for all drivers I added this new class to when I feel it is safe to do. Thanks, Wolfram signature.asc Description: Digital signature
Re: [PATCHv2] i2c: omap: Disable default probing of i2c devices for omap i2c.
On 04/09/2014 05:36 AM, Sourav Poddar wrote: > I2c core supports defualt probing functionality for devices not registered > through > dt/board files. If there are any client driver registered, i2c core will try > to > check if there is any device present corresponding to the address supplied by > the client driver. If the device is actually present and not registered, core > will register it, else the device default probe will fail and we get a omap > i2c controller > specific timeout messages. > For example, Using multi_v7_config on omap5-uevm, CONFIG_SENSORS_LM90 and > CONFIG_ICS932S401 > is the driver which is enabled and gets registered. I2c core tries to find a > valid > corresponding device on each of the address supplied by registered driver, > but could not find anyone. Hence, keep dumping the controller timeout speciic > message. > > The patch tends to disable class based instantiation, default probing will > not be attempted > by the i2c-core for omap i2c. Device will always get registered through > device tree(dt case) > and board files(for non dt cases). Conflicts against commit 04eceb00e5f793013392ad8713c645a8132f648c (i2c: i2c-omap: deprecate class based instantiation) in next-20140409 if you are dropping HWMON adap->class = I2C_CLASS_HWMON | I2C_CLASS_DEPRECATED; this might be a good time to explain why. Also drop the following testing information down into diffstat section, there is no need to retain that information in git history. > > Tested i2c enumeration and data transfer(using i2c utilities) with linux-next > master > on the following boards using omap2plus_defconfig: > * Omap3 beagle-Xm (for dt and non dt case) > * omap4 panda > * omap5-uevm > * Dra7xx > * Beaglebone white > * Beaglebone black > * am335x-evm > * AM43xx epos evm > > Tested i2c enumeration with linux-next master(except omap5) > on the following boards using multi_v7_defconfig: > * Omap3 beagle-Xm (for dt and non dt case) > * omap4 panda > * omap5-uevm (tested on next-20140131 tag, where i2c problem can be seen) > * Dra7xx > * Beaglebone white > * Beaglebone black > * am335x-evm > * AM43xx epos evm > > Cc: Felipe Balbi > Cc: Nishanth Menon > Signed-off-by: Sourav Poddar > Reported-by: Nishanth Menon > --- also indicate here against which tree and branch this patch is for. > v1->v2: > add "Reported-by" attribute > drivers/i2c/busses/i2c-omap.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 85f8eac..4ec29a0 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -1238,7 +1238,7 @@ omap_i2c_probe(struct platform_device *pdev) > adap = &dev->adapter; > i2c_set_adapdata(adap, dev); > adap->owner = THIS_MODULE; > - adap->class = I2C_CLASS_HWMON | I2C_CLASS_DEPRECATED; > + adap->class = 0; adap->class = I2C_CLASS_DEPRECATED > strlcpy(adap->name, "OMAP I2C adapter", sizeof(adap->name)); > adap->algo = &omap_i2c_algo; > adap->dev.parent = &pdev->dev; > -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] i2c: omap: Disable default probing of i2c devices for omap i2c.
I2c core supports defualt probing functionality for devices not registered through dt/board files. If there are any client driver registered, i2c core will try to check if there is any device present corresponding to the address supplied by the client driver. If the device is actually present and not registered, core will register it, else the device default probe will fail and we get a omap i2c controller specific timeout messages. For example, Using multi_v7_config on omap5-uevm, CONFIG_SENSORS_LM90 and CONFIG_ICS932S401 is the driver which is enabled and gets registered. I2c core tries to find a valid corresponding device on each of the address supplied by registered driver, but could not find anyone. Hence, keep dumping the controller timeout speciic message. The patch tends to disable class based instantiation, default probing will not be attempted by the i2c-core for omap i2c. Device will always get registered through device tree(dt case) and board files(for non dt cases). Tested i2c enumeration and data transfer(using i2c utilities) with linux-next master on the following boards using omap2plus_defconfig: * Omap3 beagle-Xm (for dt and non dt case) * omap4 panda * omap5-uevm * Dra7xx * Beaglebone white * Beaglebone black * am335x-evm * AM43xx epos evm Tested i2c enumeration with linux-next master(except omap5) on the following boards using multi_v7_defconfig: * Omap3 beagle-Xm (for dt and non dt case) * omap4 panda * omap5-uevm (tested on next-20140131 tag, where i2c problem can be seen) * Dra7xx * Beaglebone white * Beaglebone black * am335x-evm * AM43xx epos evm Cc: Felipe Balbi Cc: Nishanth Menon Signed-off-by: Sourav Poddar Reported-by: Nishanth Menon --- v1->v2: add "Reported-by" attribute drivers/i2c/busses/i2c-omap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 85f8eac..4ec29a0 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1238,7 +1238,7 @@ omap_i2c_probe(struct platform_device *pdev) adap = &dev->adapter; i2c_set_adapdata(adap, dev); adap->owner = THIS_MODULE; - adap->class = I2C_CLASS_HWMON | I2C_CLASS_DEPRECATED; + adap->class = 0; strlcpy(adap->name, "OMAP I2C adapter", sizeof(adap->name)); adap->algo = &omap_i2c_algo; adap->dev.parent = &pdev->dev; -- 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] i2c: omap: Disable default probing of i2c devices for omap i2c.
I2c core supports defualt probing functionality for devices not registered through dt/board files. If there are any client driver registered, i2c core will try to check if there is any device present corresponding to the address supplied by the client driver. If the device is actually present and not registered, core will register it, else the device default probe will fail and we get a omap i2c controller specific timeout messages. For example, Using multi_v7_config on omap5-uevm, CONFIG_SENSORS_LM90 and CONFIG_ICS932S401 is the driver which is enabled and gets registered. I2c core tries to find a valid corresponding device on each of the address supplied by registered driver, but could not find anyone. Hence, keep dumping the controller timeout speciic message. The patch tends to disable class based instantiation, default probing will not be attempted by the i2c-core for omap i2c. Device will always get registered through device tree(dt case) and board files(for non dt cases). Tested i2c enumeration and data transfer(using i2c utilities) with linux-next master on the following boards using omap2plus_defconfig: * Omap3 beagle-Xm (for dt and non dt case) * omap4 panda * omap5-uevm * Dra7xx * Beaglebone white * Beaglebone black * am335x-evm * AM43xx epos evm Tested i2c enumeration with linux-next master(except omap5) on the following boards using multi_v7_defconfig: * Omap3 beagle-Xm (for dt and non dt case) * omap4 panda * omap5-uevm (tested on next-20140131 tag, where i2c problem can be seen) * Dra7xx * Beaglebone white * Beaglebone black * am335x-evm * AM43xx epos evm Cc: Felipe Balbi Cc: Nishanth Menon Signed-off-by: Sourav Poddar --- drivers/i2c/busses/i2c-omap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 85f8eac..4ec29a0 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1238,7 +1238,7 @@ omap_i2c_probe(struct platform_device *pdev) adap = &dev->adapter; i2c_set_adapdata(adap, dev); adap->owner = THIS_MODULE; - adap->class = I2C_CLASS_HWMON | I2C_CLASS_DEPRECATED; + adap->class = 0; strlcpy(adap->name, "OMAP I2C adapter", sizeof(adap->name)); adap->algo = &omap_i2c_algo; adap->dev.parent = &pdev->dev; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Tuesday 08 April 2014 08:47 PM, Santosh Shilimkar wrote:
> On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
>> On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
>>> On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index f8b8dac..6b2a056 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
return omap_l2_cache_init(aux_ctrl, 0xc19f);
}
+
+int __init am43xx_l2_cache_init(void)
+{
+ u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
+ L310_AUX_CTRL_INSTR_PREFETCH;
>>>
>>> It would be good to documenting the difference between this and OMAP4,
>>> and why you have chosen different values.
>>
>> There are two main differences:
>>
>> 1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
>> not needed even in OMAP4 with latest kernel, but I am not sure if I can
>> do this safely without breaking any usecase currently working with OMAP4.
>>
> Wrong. Shared bit is mandatory for the OMAP4. Its a SMP system
> which needs that.
Can you please explain a little bit more since I am obviously lacking
the background on OMAP4?
Commit b0f20ff9 ("omap4: l2x0: Set share override bit") talks about
possibility of data corruption due to speculative prefetch and coherent
DMA buffers having a cachable alias. But based on recent mailing list
discussions, with introduction of CMA, we should not have such a
cachable alias since the mapping is modified in place. If
arm_memblock_steal() or memblock_remove() is used, thats not a problem
as well since that memory is not mapped in kernel page tables.
As I indicated earlier, I am too not in favor of changing anything on
OMAP4 but it will be instructive to know exactly which scenarios shared
bit becomes mandatory on OMAP4.
>> 2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
>> searched through the commit history of L2 cache support on OMAP4 but
>> there is no mention of why this was needed on OMAP4. I am checking
>> internally on the history behind this.
>>
> These have also come from the aligned settings with hardware folks.
Okay. AFAIK, There has not been such a recommendation from hardware team
of AM437x AFAIK. But, the AM437x ROM does leave these two bits set after
booting so even though Linux does not touch these, these are already set.
Given this, I see no reason for not setting the same bits again from
Linux just to get close to OMAP4 code.
>
>> 3) OMAP4 sets cache replacement policy to RR which is not a big deal
>> since thats the default anyway. We can probably drop this setting even
>> from OMAP4.
>>
> Don't change anything on OMAP4 since these settings have come up from
> multiple alignments.
I agree. Thats what the $subject series is doing too.
> In my view, Aegis can use exact same setting as OMAP4. Things like
> shared bit etc would not make much difference because of UP config,
> keeping that doesn't hurt either.
>
> Why don't you just re-use that as is ? Sorry if I have missed any
> other discussion on the thread.
We could reuse as is. I don't see any functional issue. This is what I
will probably do for the next version of the series. The only setting
thats actually being done differently is the Shared attribute override
enable bit.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
