Re: AM37x unable to drive output of some gpio lines (works with 2.6.37)

2015-10-09 Thread Rolf Peukert 
On 09.10.2015 02:54, Ladislav Michl wrote:
> Hi there!
> 
> on custom AM37x board running 2.6.37 this was enough to enable gpio 67:
> echo 71 > /sys/class/gpio/export
> echo out > /sys/class/gpio/gpio71/direction
> echo 1 > /sys/class/gpio/gpio71/value
> 
> However, with DT configured linux-4.2 compiled using omap2plus_defconfig
> this no longer works.
[...]

Is some other device driver using these pins? Pins 70 and 71 could be
DSS or UART1. Maybe you need to set them to "disabled" in your DT.

Best regards,
Rolf
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH] driver: net: cpsw: add no_bd_ram dt parsing

2015-10-09 Thread Mugunthan V N 
cpdma is capable of placing the dma descriptors in ddr using
dma_alloc_coherent() when the internal bd ram size is not enough.
To utilize this feature pass the DT parameter "no_bd_ram" and
increase bd_ram_size and number of rx descriptors.

Signed-off-by: Mugunthan V N 
---
 drivers/net/ethernet/ti/cpsw.c | 4 
 drivers/net/ethernet/ti/cpsw.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8fc90f1..cf1a625 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1987,6 +1987,8 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
data->ale_entries = prop;
 
+   data->no_bd_ram = of_property_read_bool(node, "no_bd_ram");
+
if (of_property_read_u32(node, "bd_ram_size", )) {
dev_err(>dev, "Missing bd_ram_size property in the 
DT.\n");
return -EINVAL;
@@ -2358,6 +2360,8 @@ static int cpsw_probe(struct platform_device *pdev)
dma_params.desc_mem_size= data->bd_ram_size;
dma_params.desc_align   = 16;
dma_params.has_ext_regs = true;
+   if (data->no_bd_ram)
+   dma_params.desc_mem_phys = 0;
dma_params.desc_hw_addr = dma_params.desc_mem_phys;
 
priv->dma = cpdma_ctlr_create(_params);
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index ca90efa..b654ac2 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -33,6 +33,7 @@ struct cpsw_platform_data {
u32 cpts_clock_mult;  /* convert input clock ticks to nanoseconds */
u32 cpts_clock_shift; /* convert input clock ticks to nanoseconds */
u32 ale_entries;/* ale table size */
+   boolno_bd_ram;  /* set if cpsw bd ram should not be used */
u32 bd_ram_size;  /*buffer descriptor ram size */
u32 rx_descs;   /* Number of Rx Descriptios */
u32 mac_control;/* Mac control register */
-- 
2.6.1.133.gf5b6079

--
To unsubscribe from this list: send the line "unsubscribe 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 0/2] DRA72/DRA74: Add 2 lane support

2015-10-09 Thread Kishon Vijay Abraham I 
Hi Bjorn,

On Saturday 10 October 2015 04:20 AM, Bjorn Helgaas wrote:
> [+cc Arnd, Rob]
> 
> On Mon, Sep 28, 2015 at 06:27:36PM +0530, Kishon Vijay Abraham I wrote:
>> Add driver modifications in pci-dra7xx to get x2 mode working in
>> DRA72 and DRA74. Certain modifications is needed in PHY driver also
>> which I'll send as a separate series.
>>
>> Kishon Vijay Abraham I (2):
>>   pci: host: pci-dra7xx: use "num-lanes" property to find phy count
>>   pci: host: pci-dra7xx: Enable x2 mode support
> 
> Applied to pci/host-dra7xx for v4.4, thanks!
> 
> I adjusted the subject line capitalization & format to match the history.
> 
> Arnd, Rob, any comments on the DT updates or the "num-lanes" vs number of
> strings in "phy-names" changes?

I sent it as RFC since I didn't have the board to test 2 lane mode with
$patch. And just now I got a board to test x2 and I found a problem with
the 2nd patch.

.b1co_mode_sel_mask = GENMASK(2, 3), in the patch should be replaced with
.b1co_mode_sel_mask = GENMASK(3, 2).

I'll resend the patch fixing the above.

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] sched_clock: add data pointer argument to read callback

2015-10-09 Thread Russell King - ARM Linux 
On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote:
> This passes a data pointer specified in the sched_clock_register()
> call to the read callback allowing simpler implementations thereof.
> 
> In this patch, existing uses of this interface are simply updated
> with a null pointer.

This is a bad description.  It tells us what the patch is doing,
(which we can see by reading the patch) but not _why_.  Please include
information on why the change is necessary - describe what you are
trying to achieve.

I generally don't accept patches what add new stuff to the kernel with
no users of that new stuff - that's called experience, experience of
people who submit stuff like that, and then vanish leaving their junk
in the kernel without any users.  Please ensure that this gets a user
very quickly, or better still, submit this patch as part of a series
which makes use of it.

Also, copying soo many people is guaranteed to be silently dropped by
mailing lists.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe 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] sched_clock: add data pointer argument to read callback

2015-10-09 Thread Russell King - ARM Linux 
On Sat, Oct 10, 2015 at 12:48:22AM +0100, Måns Rullgård wrote:
> Russell King - ARM Linux  writes:
> 
> > On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote:
> >> This passes a data pointer specified in the sched_clock_register()
> >> call to the read callback allowing simpler implementations thereof.
> >> 
> >> In this patch, existing uses of this interface are simply updated
> >> with a null pointer.
> >
> > This is a bad description.  It tells us what the patch is doing,
> > (which we can see by reading the patch) but not _why_.  Please include
> > information on why the change is necessary - describe what you are
> > trying to achieve.
> 
> Currently most of the callbacks use a global variable to store the
> address of a counter register.  This has several downsides:
> 
> - Loading the address of a global variable can be more expensive than
>   keeping a pointer next to the function pointer.
> 
> - It makes it impossible to have multiple instances of a driver call
>   sched_clock_register() since the caller can't know which clock will
>   win in the end.
> 
> - Many of the existing callbacks are practically identical and could be
>   replaced with a common generic function if it had a pointer argument.
> 
> If I've missed something that makes this a stupid idea, please tell.

So my next question is whether you intend to pass an iomem pointer
through this, or a some kind of structure, or both.  It matters,
because iomem pointers have a __iomem attribute to keep sparse
happy.  Having to force that attribute on and off pointers is frowned
upon, as it defeats the purpose of the sparse static checker.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe 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 0/2] DRA72/DRA74: Add 2 lane support

2015-10-09 Thread Bjorn Helgaas 
On Sat, Oct 10, 2015 at 04:46:55AM +0530, Kishon Vijay Abraham I wrote:
> Hi Bjorn,
> 
> On Saturday 10 October 2015 04:20 AM, Bjorn Helgaas wrote:
> > [+cc Arnd, Rob]
> > 
> > On Mon, Sep 28, 2015 at 06:27:36PM +0530, Kishon Vijay Abraham I wrote:
> >> Add driver modifications in pci-dra7xx to get x2 mode working in
> >> DRA72 and DRA74. Certain modifications is needed in PHY driver also
> >> which I'll send as a separate series.
> >>
> >> Kishon Vijay Abraham I (2):
> >>   pci: host: pci-dra7xx: use "num-lanes" property to find phy count
> >>   pci: host: pci-dra7xx: Enable x2 mode support
> > 
> > Applied to pci/host-dra7xx for v4.4, thanks!
> > 
> > I adjusted the subject line capitalization & format to match the history.
> > 
> > Arnd, Rob, any comments on the DT updates or the "num-lanes" vs number of
> > strings in "phy-names" changes?
> 
> I sent it as RFC since I didn't have the board to test 2 lane mode with
> $patch. And just now I got a board to test x2 and I found a problem with
> the 2nd patch.
> 
> .b1co_mode_sel_mask = GENMASK(2, 3), in the patch should be replaced with
> .b1co_mode_sel_mask = GENMASK(3, 2).
> 
> I'll resend the patch fixing the above.

OK, I dropped these two patches.  Thanks for letting me know.
--
To unsubscribe from this list: send the line "unsubscribe 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] sched_clock: add data pointer argument to read callback

2015-10-09 Thread Måns Rullgård 
Russell King - ARM Linux  writes:

> On Sat, Oct 10, 2015 at 12:48:22AM +0100, Måns Rullgård wrote:
>> Russell King - ARM Linux  writes:
>> 
>> > On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote:
>> >> This passes a data pointer specified in the sched_clock_register()
>> >> call to the read callback allowing simpler implementations thereof.
>> >> 
>> >> In this patch, existing uses of this interface are simply updated
>> >> with a null pointer.
>> >
>> > This is a bad description.  It tells us what the patch is doing,
>> > (which we can see by reading the patch) but not _why_.  Please include
>> > information on why the change is necessary - describe what you are
>> > trying to achieve.
>> 
>> Currently most of the callbacks use a global variable to store the
>> address of a counter register.  This has several downsides:
>> 
>> - Loading the address of a global variable can be more expensive than
>>   keeping a pointer next to the function pointer.
>> 
>> - It makes it impossible to have multiple instances of a driver call
>>   sched_clock_register() since the caller can't know which clock will
>>   win in the end.
>> 
>> - Many of the existing callbacks are practically identical and could be
>>   replaced with a common generic function if it had a pointer argument.
>> 
>> If I've missed something that makes this a stupid idea, please tell.
>
> So my next question is whether you intend to pass an iomem pointer
> through this, or a some kind of structure, or both.  It matters,
> because iomem pointers have a __iomem attribute to keep sparse
> happy.  Having to force that attribute on and off pointers is frowned
> upon, as it defeats the purpose of the sparse static checker.

So this is an instance where tools like sparse get in the way of doing
the simplest, most efficient, and obviously correct thing.  Who wins in
such cases?

-- 
Måns Rullgård
m...@mansr.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: [RFC PATCH 0/2] DRA72/DRA74: Add 2 lane support

2015-10-09 Thread Kishon Vijay Abraham I 
Hi,

On Saturday 10 October 2015 04:46 AM, Kishon Vijay Abraham I wrote:
> Hi Bjorn,
> 
> On Saturday 10 October 2015 04:20 AM, Bjorn Helgaas wrote:
>> [+cc Arnd, Rob]
>>
>> On Mon, Sep 28, 2015 at 06:27:36PM +0530, Kishon Vijay Abraham I wrote:
>>> Add driver modifications in pci-dra7xx to get x2 mode working in
>>> DRA72 and DRA74. Certain modifications is needed in PHY driver also
>>> which I'll send as a separate series.
>>>
>>> Kishon Vijay Abraham I (2):
>>>   pci: host: pci-dra7xx: use "num-lanes" property to find phy count
>>>   pci: host: pci-dra7xx: Enable x2 mode support
>>
>> Applied to pci/host-dra7xx for v4.4, thanks!
>>
>> I adjusted the subject line capitalization & format to match the history.
>>
>> Arnd, Rob, any comments on the DT updates or the "num-lanes" vs number of
>> strings in "phy-names" changes?
> 
> I sent it as RFC since I didn't have the board to test 2 lane mode with
> $patch. And just now I got a board to test x2 and I found a problem with
> the 2nd patch.
> 
> .b1co_mode_sel_mask = GENMASK(2, 3), in the patch should be replaced with
> .b1co_mode_sel_mask = GENMASK(3, 2).
> 
> I'll resend the patch fixing the above.

I'll resend after a couple of days to fix any comments from Arnd or Rob.

Thanks
Kishon

> 
> Thanks
> Kishon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 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] sched_clock: add data pointer argument to read callback

2015-10-09 Thread Måns Rullgård 
Russell King - ARM Linux  writes:

> On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote:
>> This passes a data pointer specified in the sched_clock_register()
>> call to the read callback allowing simpler implementations thereof.
>> 
>> In this patch, existing uses of this interface are simply updated
>> with a null pointer.
>
> This is a bad description.  It tells us what the patch is doing,
> (which we can see by reading the patch) but not _why_.  Please include
> information on why the change is necessary - describe what you are
> trying to achieve.

Currently most of the callbacks use a global variable to store the
address of a counter register.  This has several downsides:

- Loading the address of a global variable can be more expensive than
  keeping a pointer next to the function pointer.

- It makes it impossible to have multiple instances of a driver call
  sched_clock_register() since the caller can't know which clock will
  win in the end.

- Many of the existing callbacks are practically identical and could be
  replaced with a common generic function if it had a pointer argument.

If I've missed something that makes this a stupid idea, please tell.

-- 
Måns Rullgård
m...@mansr.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: [RFC PATCH 0/2] DRA72/DRA74: Add 2 lane support

2015-10-09 Thread Bjorn Helgaas 
[+cc Arnd, Rob]

On Mon, Sep 28, 2015 at 06:27:36PM +0530, Kishon Vijay Abraham I wrote:
> Add driver modifications in pci-dra7xx to get x2 mode working in
> DRA72 and DRA74. Certain modifications is needed in PHY driver also
> which I'll send as a separate series.
> 
> Kishon Vijay Abraham I (2):
>   pci: host: pci-dra7xx: use "num-lanes" property to find phy count
>   pci: host: pci-dra7xx: Enable x2 mode support

Applied to pci/host-dra7xx for v4.4, thanks!

I adjusted the subject line capitalization & format to match the history.

Arnd, Rob, any comments on the DT updates or the "num-lanes" vs number of
strings in "phy-names" changes?

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe 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+: Fixed inverted OMAP_OFFOUT_EN

2015-10-09 Thread Ben Tucker 
On Fri, Oct 09, 2015 at 09:16:28AM -0700, Tony Lindgren wrote:
> * Ben Tucker  [151009 03:20]:
> > On Thu, Oct 08, 2015 at 11:40:06PM -0700, Tony Lindgren wrote:
> > > * Ben Tucker  [151008 06:09]:
> > > > The OFFOUTENABLE bit of the omap PADCONF registers is active low.
> > > > The mux code assumed that it was active high and this patch fixes this
> > > > problem.
> > > > 
> > > > Tested on an AM37x device.
> > > 
> > > Hmm what are the test cases you're using to validate this so
> > > I can try to reproduce?
> > 
> > I have a GSM modem connected to the omap via uart. The modem will only
> > enter a low power sleep mode when is RXD is pulled low, so by using the
> > OFFOUTENABLE signal I am able to automatically activate low power in the
> > modem when suspending to off.
> > I have a test setup which allows me to measure the combined power used by 
> > the
> > omap+modem and I can see a saving of around 45mA in suspend with this
> > patch. This is consistent with the literature on the modem device.
> 
> OK that pin may be then glitchy because of 1.158 :)
> 
> > Our custom hardware is based on omap3beagle and not available to you. My
> > thoughts as to reproducing this would be to use a beagle and setup so
> > that it is able to suspend right down to CORE Off. Then set up the pin
> > muxing for the UART TX signal to output low in off mode. It should be
> > possible to measure the level on the TX signal in suspend.
> 
> Hmm well UART will be powered off, but I can use any GPIO pin for
> that.
> 
> > I appreciate that this is a lot of work. I would be happy to do this
> > but it will take some time. Would you be able to help get things up and
> > running?
> > 
> > > 
> > > AFAIK because of erratum 1.158 for GPIO pins needing to be
> > > muxed temporarly for input + pull + safe mode for off mode,
> > > so I'm wondering in which cases the OFFOUTENABLE can be used.
> > 
> > In my scenario the pin is muxed to the uart function (TxD), but I am
> > interested in this issue as well. First off, I want to read the erratum
> > 1.158 you speak of.
> > I see that the errata document for OMAP35xx has:
> > Advisory 3.1.1.158 Pull-up not maintained on pin corresponding to
> > GPIO_28/29 during padconf restore
> > Is this what you are referring to?
> 
> Hmm I believe it has some different TI external number. Maybe search
> for 1.158 and Tero Kristo and you come up with an older patch
> implementing the workaround. I have not seen the errata description
> either.
Yes, I found that patch or a variant of it before. I think it most
closely matches the TI advisories:

- sprz278f.pdf (omap35xx)
Advisory 3.1.1.160 GPIO Pad Glitch/Spike Upon Wake-Up From System OFF Mode

- sprz318f.pdf (am37x)
Advisory 1.45 GPIO Pad Spurious Transition (Glitch/Spike) During Wake Up 
Entering or Exiting System OFF Mode

>From my understanding both of these advisories include the work around
to switch to off mode input and pull up or down to mimic the gpio output level
(which is fine so long as the pin is lightly loaded). Looks like this is
what the patch does.

> 
> > > I have a patch in works for 1.158 using gpio-ranges, and the
> > > test case I'm using is the reset of WLAN that happens in off
> > > mode as the enable GPIO glitches when returning from off mode.
> > 
> > I will now go away and have a look through all the places that we use
> > GPIO and asses the impact of glitches on the signals in our design.
> > Thankyou.
> 
> Yup, I've verified it happens on a scope earlier. If you have
> external pulls you may not experience this issue.
> 
> > > Also.. I'm wondring why this has not been caught earlier?
> > > Maybe because 1.158 is needed on omap3?
> > 
> > Maybe. Also the use of OFFOUTENABLE in combination with peripherals
> > other than GPIO, I guess, is pretty rare.
> 
> Right, I guess it has not been used :)
> 
> Hmm so what's the use case for PIN_OFF_INPUT* then?
On the face of it if the peripheral behind the pin is powered off which
will be the case when we have powered the domains off, then it cannot
process any input values.

However there are two uses for input off mode I can think of:

1- the pin is not connected, in which case you want to make it an input
so that there is no driver enabled for it. I am guessing this would save
a little power even though the pin has no load. Note an internal pull
resister should be enabled in this case to avoid the pin acting like a
aerial and switching internal logic, which again would be a source of
power draw.
(Having just read the TRM, I see that the safe-mode can be used for most
N/C pins)

2- we want to enable a wakeup of the system on the pin


Something else you may want to look out for is the fact that the omap4
mux config is has the same active low OFFOUTENABLE as omap3. I do not
know if the same problem exists in the omap4 mux control code. I do not
think it is shared with the omap3 mux control code.
(Just my 2p worth)


Thanks,

Re: [RFC] AM35xx glue code for M-USB driver

2015-10-09 Thread Felipe Balbi 

Hi,

Rolf Peukert  writes:
> Hi Felipe,
>
> On 07.10.2015 18:22, Felipe Balbi wrote:
> [...]
> b) The M-USB port on our board is wired as host only. If a device is
> unplugged, the driver normally goes into some idle state and waits for
> an ID signal change. But on our board that never happens.

 did you route ID pin anywhere ? I hope you tied it to ground.
>>>
>>> I think so. I'll double-check that.
>> 
>> cool, thanks.
>
> The ID pin was not connected, it's tied to ground now, but still the
> same behaviour. But I can keep it from entering the musb_try_idle
> function by deactivating the vbus timeout. This can be done from
> userspace, so we don't need the additional if-statements in the code.

okay, eventually we want things to work without relying on userspace
though. For now, it should be enough to do what you're doing so we focus
on other issues.

>>> [...]
> + /* Set defaults */
> + config->num_eps = 16;
> + config->ram_bits = 12;
> + config->multipoint = true;

 all of these are board-specific.

> +
> + bdata->interface_type = MUSB_INTERFACE_UTMI;
> + bdata->mode = MUSB_OTG;
> + bdata->power = 500;
> + bdata->extvbus = 1;

 so are these.
>
> OK, if everything is declared in the device tree, we don't need to set
> default values here.

right.

> Regarding the four am35x_... functions from omap_phy_internal.c, it's
> not easy to move them over to am35x.c.
> While they just set a few bits in some system control module registers,
> they call functions from control.c to access the SCM. The control.c
> functions are not exported either (and use some static variables and
> also local include files from mach-omap2).

yeah, there's still quite a bit left to clean up for those devices and,
unfortunately, I don't even have them available so I can't help much :-s

>>> [...]
> + phy_clk = clk_get(>dev, "hsotgusb_fck");

 why did you change the clock name ? That shouldn't be necessary.
>>>
>>> I did get "failed to get PHY clock" and "failed to get clock"
>>> messages.
>> 
>> right, this a bug elsewhere. Drivers shouldn't care about the exact
>> clock name ;-)
>> 
>
> The corresponding clock declaration seems to be in
> drivers/clk/ti/clk-3xxx.c:
>
>   DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
>   DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
>
> When I add two more lines there,
>
>   DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
>   DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
>
> the "ick" and "fck" clocks are found. It doesn't work without the
> address in the device name, and not with just "musb-am35x" either.

right, you need to pass the correct device name. This alone is a bug fix
worth sending. But send this two-line change as a single patch, a single
bug fix with nothing else in it.

> Still, all other device names in that file look simpler, and I'm
> wondering if I forgot a proper name declaration somewhere else?

no, you're correct. Those other devices are likely broken on DT boots
too, dunno for sure.

-- 
balbi


signature.asc
Description: PGP signature

Re: [RFC] AM35xx glue code for M-USB driver

2015-10-09 Thread Rolf Peukert 
Hi Felipe,

On 07.10.2015 18:22, Felipe Balbi wrote:
[...]
 b) The M-USB port on our board is wired as host only. If a device is
 unplugged, the driver normally goes into some idle state and waits for
 an ID signal change. But on our board that never happens.
>>>
>>> did you route ID pin anywhere ? I hope you tied it to ground.
>>
>> I think so. I'll double-check that.
> 
> cool, thanks.

The ID pin was not connected, it's tied to ground now, but still the
same behaviour. But I can keep it from entering the musb_try_idle
function by deactivating the vbus timeout. This can be done from
userspace, so we don't need the additional if-statements in the code.

>> [...]
 +  /* Set defaults */
 +  config->num_eps = 16;
 +  config->ram_bits = 12;
 +  config->multipoint = true;
>>>
>>> all of these are board-specific.
>>>
 +
 +  bdata->interface_type = MUSB_INTERFACE_UTMI;
 +  bdata->mode = MUSB_OTG;
 +  bdata->power = 500;
 +  bdata->extvbus = 1;
>>>
>>> so are these.

OK, if everything is declared in the device tree, we don't need to set
default values here.

Regarding the four am35x_... functions from omap_phy_internal.c, it's
not easy to move them over to am35x.c.
While they just set a few bits in some system control module registers,
they call functions from control.c to access the SCM. The control.c
functions are not exported either (and use some static variables and
also local include files from mach-omap2).

>> [...]
 +  phy_clk = clk_get(>dev, "hsotgusb_fck");
>>>
>>> why did you change the clock name ? That shouldn't be necessary.
>>
>> I did get "failed to get PHY clock" and "failed to get clock"
>> messages.
> 
> right, this a bug elsewhere. Drivers shouldn't care about the exact
> clock name ;-)
> 

The corresponding clock declaration seems to be in
drivers/clk/ti/clk-3xxx.c:

DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),

When I add two more lines there,

DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),

the "ick" and "fck" clocks are found. It doesn't work without the
address in the device name, and not with just "musb-am35x" either.
Still, all other device names in that file look simpler, and I'm
wondering if I forgot a proper name declaration somewhere else?

Best regards,
Rolf

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html