Re: [PATCH 11/13] arm: dts: dra7: add DMA properties for UART
On Tue, Nov 04, 2014 at 04:03:15PM -0500, Lennart Sorensen wrote: > So it seems to be working on our board so far. Will stress test it > some more. No DMA of course for now, but oh well. Well 4 hours running with multiple reboots (our testsuite reboots every 30 minutes to test the watchdog). So far it has only lost 70 bytes out of 40MB of data sent between uart7 and uart8 (and we are pretty sure the serial test has a small bug that causes a few bytes to be lost right after a reboot sometimes). The reason I am even trying the new driver today is that we were seeing soft lockups on the CPU whenever the serial ports were being tested, usually in less than 5 minutes, so 4 hours without a lockup is a good sign. No idea what might be wrong with the old omap serial driver, but it seems something is (unless of course we managed to break it somehow when we tried to solve its habit of dropping characters). I think I will stick with this new driver. Better long term future anyhow. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe 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: N900 modem support in 3.18-rc1
Hi Pavel, On Tue, Nov 04, 2014 at 09:51:17PM +0100, Pavel Machek wrote: > I'd like to test a modem (and eventually to get it to work :-) ) on > n900. So far I found: > > http://lwn.net/Articles/592485/ > > It says: > > # supported. Testing the patchset with ofono works like this: > # > # # provide cmt device for ofono > # ln -sf /sys/bus/hsi/n900-modem /dev/cmt > > [...] > > That seemed to match, so I symlinked it. looks ok. You should have the following files: /dev/cmt/cmt_apeslpx /dev/cmt/cmt_bsi /dev/cmt/cmt_en /dev/cmt/cmt_rst_rq /dev/cmt/cmt_rst Apart from that the kernel should be provide a phonet0 network device. > # # start ofono > # ofono --nodetach --debug > > It it a typo and it wants ofonod? yes. > root@n900:~# ofonod --nodetach --debug & > [1] 3552 no output from ofono? > root@n900:~# mdbus2 -s org.ofono /n900_0 xyz > [ERR]: There is no method with name xyz on path /n900_0! > > [...] > > Any ideas? call mdbus2 with fewer arguments to see what is available on the bus: mdbus2 -s => list all system services mdbus2 -s org.ofono=> list all ofono objects mdbus2 -s org.ofono /n900_0=> list all methods from n900 object -- Sebastian signature.asc Description: Digital signature
Re: [RFCv2 5/8] [media] si4713: add device tree support
Hi Sebastian,
Nice set of patches! Thanks! :-)
On Tue, Oct 21, 2014 at 05:07:04PM +0200, Sebastian Reichel wrote:
> Add device tree support by changing the device registration order.
> In the device tree the si4713 node is a normal I2C device, which
> will be probed as such. Thus the V4L device must be probed from
> the I2C device and not the other way around.
>
> Signed-off-by: Sebastian Reichel
> ---
> drivers/media/radio/si4713/radio-platform-si4713.c | 28 --
> drivers/media/radio/si4713/si4713.c| 34
> --
> drivers/media/radio/si4713/si4713.h| 6
> include/media/radio-si4713.h | 30 ---
> include/media/si4713.h | 1 +
> 5 files changed, 45 insertions(+), 54 deletions(-)
> delete mode 100644 include/media/radio-si4713.h
>
> diff --git a/drivers/media/radio/si4713/radio-platform-si4713.c
> b/drivers/media/radio/si4713/radio-platform-si4713.c
> index a47502a..2de5439 100644
> --- a/drivers/media/radio/si4713/radio-platform-si4713.c
> +++ b/drivers/media/radio/si4713/radio-platform-si4713.c
> @@ -34,7 +34,7 @@
> #include
> #include
> #include
> -#include
> +#include "si4713.h"
>
> /* module parameters */
> static int radio_nr = -1;/* radio device minor (-1 ==> auto assign) */
> @@ -153,7 +153,6 @@ static int radio_si4713_pdriver_probe(struct
> platform_device *pdev)
> {
> struct radio_si4713_platform_data *pdata = pdev->dev.platform_data;
> struct radio_si4713_device *rsdev;
> - struct i2c_adapter *adapter;
> struct v4l2_subdev *sd;
> int rval = 0;
>
> @@ -177,20 +176,11 @@ static int radio_si4713_pdriver_probe(struct
> platform_device *pdev)
> goto exit;
> }
>
> - adapter = i2c_get_adapter(pdata->i2c_bus);
> - if (!adapter) {
> - dev_err(&pdev->dev, "Cannot get i2c adapter %d\n",
> - pdata->i2c_bus);
> - rval = -ENODEV;
> - goto unregister_v4l2_dev;
> - }
> -
> - sd = v4l2_i2c_new_subdev_board(&rsdev->v4l2_dev, adapter,
> -pdata->subdev_board_info, NULL);
> - if (!sd) {
> + sd = i2c_get_clientdata(pdata->subdev);
> + rval = v4l2_device_register_subdev(&rsdev->v4l2_dev, sd);
> + if (rval) {
> dev_err(&pdev->dev, "Cannot get v4l2 subdevice\n");
> - rval = -ENODEV;
> - goto put_adapter;
> + goto unregister_v4l2_dev;
> }
>
> rsdev->radio_dev = radio_si4713_vdev_template;
> @@ -202,14 +192,12 @@ static int radio_si4713_pdriver_probe(struct
> platform_device *pdev)
> if (video_register_device(&rsdev->radio_dev, VFL_TYPE_RADIO, radio_nr))
> {
> dev_err(&pdev->dev, "Could not register video device.\n");
> rval = -EIO;
> - goto put_adapter;
> + goto unregister_v4l2_dev;
> }
> dev_info(&pdev->dev, "New device successfully probed\n");
>
> goto exit;
>
> -put_adapter:
> - i2c_put_adapter(adapter);
> unregister_v4l2_dev:
> v4l2_device_unregister(&rsdev->v4l2_dev);
> exit:
> @@ -220,14 +208,10 @@ exit:
> static int radio_si4713_pdriver_remove(struct platform_device *pdev)
> {
> struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
> - struct v4l2_subdev *sd = list_entry(v4l2_dev->subdevs.next,
> - struct v4l2_subdev, list);
> - struct i2c_client *client = v4l2_get_subdevdata(sd);
> struct radio_si4713_device *rsdev;
>
> rsdev = container_of(v4l2_dev, struct radio_si4713_device, v4l2_dev);
> video_unregister_device(&rsdev->radio_dev);
> - i2c_put_adapter(client->adapter);
> v4l2_device_unregister(&rsdev->v4l2_dev);
>
> return 0;
> diff --git a/drivers/media/radio/si4713/si4713.c
> b/drivers/media/radio/si4713/si4713.c
> index ebec16d..94fe3c6 100644
> --- a/drivers/media/radio/si4713/si4713.c
> +++ b/drivers/media/radio/si4713/si4713.c
> @@ -1446,9 +1446,13 @@ static int si4713_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> struct si4713_device *sdev;
> - struct si4713_platform_data *pdata = client->dev.platform_data;
> struct v4l2_ctrl_handler *hdl;
> - int rval, i;
> + struct si4713_platform_data *pdata = client->dev.platform_data;
> + struct device_node *np = client->dev.of_node;
> + int rval;
> +
Why empty line here?
It's not a bad practice to declare short temporary variables etc. as last.
> + struct radio_si4713_platform_data si4713_pdev_pdata;
> + struct platform_device *si4713_pdev;
>
> sdev = devm_kzalloc(&client->dev, sizeof(*sdev), GFP_KERNEL);
> if (!sdev) {
> @@ -1608,8 +1612,31 @@ static int si4713_probe(struct i2c_client *client,
> goto free_ctrls;
> }
>
> + if ((pdata
Re: [PATCH 11/13] arm: dts: dra7: add DMA properties for UART
On Tue, Nov 04, 2014 at 01:33:15PM -0500, Lennart Sorensen wrote: > Well it doesn't work, because I don't have the dma croassbar patches > from ti-linux-3.14.y which are required to use the full range of dma > channels on the dra7. > > I will see how well it works without dma at least. So it seems to be working on our board so far. Will stress test it some more. No DMA of course for now, but oh well. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
N900 modem support in 3.18-rc1
Hi! I'd like to test a modem (and eventually to get it to work :-) ) on n900. So far I found: http://lwn.net/Articles/592485/ It says: # supported. Testing the patchset with ofono works like this: # # # provide cmt device for ofono # ln -sf /sys/bus/hsi/n900-modem /dev/cmt root@n900:/dev# ln -sf /sys/bus/hsi/n900-modem /dev/cmt root@n900:/dev# ls -al /dev/cmt lrwxrwxrwx 1 root root 23 Jan 1 08:51 /dev/cmt -> /sys/bus/hsi/n900-modem root@n900:/dev# cat /dev/cmt cat: /dev/cmt: No such file or directory root@n900:/dev# cd /dev/cmt -bash: cd: /dev/cmt: No such file or directory root@n900:/dev# root@n900:/dev# ls -al /sys/bus/hsi/ devices/ drivers_autoprobe uevent drivers/ drivers_probe root@n900:/dev# ls -al /sys/bus/hsi/devices/ cmt_speech/ hsi_char/ n900-modem/ ssi-protocol/ root@n900:/dev# ls -al /sys/bus/hsi/devices/n900-modem lrwxrwxrwx 1 root root 0 Jan 1 08:46 /sys/bus/hsi/devices/n900-modem -> ../../../devices/6800.ocp/48058000.ssi-controller/ssi0/port0/n900-modem root@n900:/dev# That seemed to match, so I symlinked it. # # start ofono # ofono --nodetach --debug It it a typo and it wants ofonod? root@n900:~# ofonod --nodetach --debug & [1] 3552 root@n900:~# ofonod[3552]: oFono version 1.6 # # enable the modem # mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Powered true root@n900:~# mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Powered true [ERR]: There is no method with name org.ofono.Modem.SetProperty on path /n900_0! # # enable modem's RF parts # mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Online true root@n900:~# mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Online true [ERR]: There is no method with name org.ofono.Modem.SetProperty on path /n900_0! # # scan for available networks (takes some time) # mdbus2 -s org.ofono /n900_0 org.ofono.NetworkRegistration.Scan root@n900:~# mdbus2 -s org.ofono /n900_0 org.ofono.NetworkRegistration.Scan [ERR]: There is no method with name org.ofono.NetworkRegistration.Scan on path /n900_0! Any ideas? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/5] ARM: OMAP2+: gpmc: Print error message in set_gpmc_timing_reg()
On Tuesday 21 October 2014 06:11 PM, Roger Quadros wrote: Simplify set_gpmc_timing_reg() and always print error message if the requested timing cannot be achieved due to a too fast GPMC functional clock, irrespective if whether DEBUG is defined or not. This should help us debug timing configuration issues, which were otherwise simply not being displayed in the kernel log. Signed-off-by: Roger Quadros Signed-off-by: Sekhar Nori --- Thanks for this patch. Its helpful in tweaking NAND signal timing, while trying to squeeze read/write performance especially with new NAND devices. with regards, pekon Powered by BigRock.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 11/13] arm: dts: dra7: add DMA properties for UART
On Tue, Nov 04, 2014 at 07:32:07PM +0100, Javier Martinez Canillas wrote: > Hello, > > On Tue, Nov 4, 2014 at 6:21 PM, Lennart Sorensen > wrote: > >> Mind sharing the manual with me? Mine does not mention DMA channels for > >> UART7-10. If you are able to test 7+8 (and it works) could you please > >> make patch which with for the remaining four devices? > > > > Well the file I have is called AM572x_ES1.1_NDA_TRM_vT.pdf, so I am not > > sure who I am allowed to share that file with. Might be simpler to just > > ask TI for the latest version. > > > > How I hate NDAs. > > > > I saw today an announcement about a public AM572x Silicon Revision 1.1 > TRM [0] that has just made available by TI. I'm not familiar with this > SoC so I don't know if that has the information you want but I thought > it was worth to mention in case it did. > > Best regards, > Javier > > [0]: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf That's the right one. Page 3622 has the dma channels for uart 7 through 10, but it still needs the updated crossbar dma driver to work. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe 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 11/13] arm: dts: dra7: add DMA properties for UART
On 11/04/2014 12:32 PM, Javier Martinez Canillas wrote: > Hello, > > On Tue, Nov 4, 2014 at 6:21 PM, Lennart Sorensen > wrote: >>> Mind sharing the manual with me? Mine does not mention DMA channels for >>> UART7-10. If you are able to test 7+8 (and it works) could you please >>> make patch which with for the remaining four devices? >> >> Well the file I have is called AM572x_ES1.1_NDA_TRM_vT.pdf, so I am not >> sure who I am allowed to share that file with. Might be simpler to just >> ask TI for the latest version. >> >> How I hate NDAs. >> > > I saw today an announcement about a public AM572x Silicon Revision 1.1 > TRM [0] that has just made available by TI. I'm not familiar with this > SoC so I don't know if that has the information you want but I thought > it was worth to mention in case it did. > > Best regards, > Javier > > [0]: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf Same chip. -- 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: [PATCH 11/13] arm: dts: dra7: add DMA properties for UART
On Tue, Nov 04, 2014 at 12:21:17PM -0500, Lennart Sorensen wrote: > Well the file I have is called AM572x_ES1.1_NDA_TRM_vT.pdf, so I am not > sure who I am allowed to share that file with. Might be simpler to just > ask TI for the latest version. > > How I hate NDAs. Well it doesn't work, because I don't have the dma croassbar patches from ti-linux-3.14.y which are required to use the full range of dma channels on the dra7. I will see how well it works without dma at least. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe 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 11/13] arm: dts: dra7: add DMA properties for UART
Hello, On Tue, Nov 4, 2014 at 6:21 PM, Lennart Sorensen wrote: >> Mind sharing the manual with me? Mine does not mention DMA channels for >> UART7-10. If you are able to test 7+8 (and it works) could you please >> make patch which with for the remaining four devices? > > Well the file I have is called AM572x_ES1.1_NDA_TRM_vT.pdf, so I am not > sure who I am allowed to share that file with. Might be simpler to just > ask TI for the latest version. > > How I hate NDAs. > I saw today an announcement about a public AM572x Silicon Revision 1.1 TRM [0] that has just made available by TI. I'm not familiar with this SoC so I don't know if that has the information you want but I thought it was worth to mention in case it did. Best regards, Javier [0]: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf -- To unsubscribe from this list: send the line "unsubscribe 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] mfd: twl4030-power: Fix poweroff with PM configuration enabled
* Igor Grinberg [141104 09:54]:
> On 11/04/14 17:42, Tony Lindgren wrote:
> > * Igor Grinberg [141104 05:22]:
> >> Hi Tony,
> >>
> >> On 11/02/14 20:07, Tony Lindgren wrote:
> >>> Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset
> >>> configuration") enabled configuring the PM features for twl4030.
> >>>
> >>> This caused poweroff command to fail on devices that have the
> >>> BCI charger on twl4030 wired, or have power wired for VBUS.
> >>> Instead of powering off, the device reboots. This is because
> >>> voltage is detected on charger or VBUS with the default bits
> >>> enabled for the power transition registers.
> >>>
> >>> To fix the issue, let's just clear VBUS and CHG bits as we want
> >>> poweroff command to keep the system powered off.
> >>
> >> What about devices that really need to start once VBUS or CHG is connected?
> >
> > More handling can be added for some cases. With this patch the
> > poweron bits will clear to defaults if power is completely removed.
> > So start-up with VBUS and CHG works in that case.
> >
> > However, if you have a battery connected, and you poweroff, with
> > this patch the device won't power up with VBUS or CHG connected.
> >
> > Note that most battery operated devices are not using the charger
> > on twl4030 because it has issues charging a completely empty
> > battery AFAIK. So most battery powered devices have been using an
> > external USB charger chip that's not affected by this patch.
> >
> > We could consider exporting a function for the charger driver to
> > configure the poweron mask. And we could also consider passing a
> > mask in ti,use_poweroff = 0xff.
>
> Ok. That sounds better to me.
> Yet, if you say there are no such devices in practice,
> IMHO, we can merge this.
>
> >> It seems to me that forcing these bits on power off can break that kind of
> >> devices and these settings should really be board specific.
> >> What do you think?
> >
> > There's a patch series for "[RFC,01/16] kernel: Add support for
> > poweroff handler call chain" that should help with that. For sure
> > the poweroff handling needs to be board specific as some systems
> > may need to use a GPIO to shut off a regulator powering something
> > before powering off the SoC.
>
> Yes, I've seen this series.
> I'm not sure though that I understand how is this supposed
> to be used with DT...
> Through the regulator bindings?
> Which will tell it to hook up on the call chain?
Yes that should be doable with regulator bindings for board specifc
configuration. For the SoC specific functions those can be registered
by the platform code.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl4030-power: Fix poweroff with PM configuration enabled
On 11/04/14 17:42, Tony Lindgren wrote:
> * Igor Grinberg [141104 05:22]:
>> Hi Tony,
>>
>> On 11/02/14 20:07, Tony Lindgren wrote:
>>> Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset
>>> configuration") enabled configuring the PM features for twl4030.
>>>
>>> This caused poweroff command to fail on devices that have the
>>> BCI charger on twl4030 wired, or have power wired for VBUS.
>>> Instead of powering off, the device reboots. This is because
>>> voltage is detected on charger or VBUS with the default bits
>>> enabled for the power transition registers.
>>>
>>> To fix the issue, let's just clear VBUS and CHG bits as we want
>>> poweroff command to keep the system powered off.
>>
>> What about devices that really need to start once VBUS or CHG is connected?
>
> More handling can be added for some cases. With this patch the
> poweron bits will clear to defaults if power is completely removed.
> So start-up with VBUS and CHG works in that case.
>
> However, if you have a battery connected, and you poweroff, with
> this patch the device won't power up with VBUS or CHG connected.
>
> Note that most battery operated devices are not using the charger
> on twl4030 because it has issues charging a completely empty
> battery AFAIK. So most battery powered devices have been using an
> external USB charger chip that's not affected by this patch.
>
> We could consider exporting a function for the charger driver to
> configure the poweron mask. And we could also consider passing a
> mask in ti,use_poweroff = 0xff.
Ok. That sounds better to me.
Yet, if you say there are no such devices in practice,
IMHO, we can merge this.
>
>> It seems to me that forcing these bits on power off can break that kind of
>> devices and these settings should really be board specific.
>> What do you think?
>
> There's a patch series for "[RFC,01/16] kernel: Add support for
> poweroff handler call chain" that should help with that. For sure
> the poweroff handling needs to be board specific as some systems
> may need to use a GPIO to shut off a regulator powering something
> before powering off the SoC.
Yes, I've seen this series.
I'm not sure though that I understand how is this supposed
to be used with DT...
Through the regulator bindings?
Which will tell it to hook up on the call chain?
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] ARM: OMAP2+: gpmc: configuration enhancements
* Roger Quadros [141030 08:25]: > On 10/30/2014 05:10 PM, Tony Lindgren wrote: > > * Roger Quadros [141021 05:43]: > >> Hi Tony, > >> > >> These patches address GPMC configuration issues and are for v3.19. > >> Patches based on v3.18-rc1. > >> > >> - Make sure to print a user visible error if a requested GPMC timing > >> configuration can't be met. > >> > >> - Don't create GPMC child device if a GPMC timing could not be set. > >> > >> - Always enable address lines A26-A11 for non-NAND devices. > >> > >> - Perform GPMC configuration as per recommended procedure i.e. > >> keep Chip Select disabled while changing GPMC configuration. > >> > >> Tested on dra7-evm, am437x-gp-evm and beagleboard. > > > > For all these, please feel free to add: > > > > Acked-by: Tony Lindgren > > > > Thanks. These patches are now available at > > g...@github.com:rogerq/linux.git for-v3.19/gpmc-omap > Merged these on top of the patches I did to omap-for-v3.19/gpmc. There were few merge conflicts so you may want to check. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] arm: dts: dra7: add DMA properties for UART
On Tue, Nov 04, 2014 at 06:06:37PM +0100, Sebastian Andrzej Siewior wrote: > On 11/04/2014 06:02 PM, Lennart Sorensen wrote: > > > > According to the manual the DMA channels for UART7 to 10 are: > > > > uart7: 144 145 > > uart8: 146 147 > > uart9: 148 149 > > uart10: 150 151 > > > > Might as well add those too. We have uart 7 and 8 in use on our board > > so I am about to go test it. > > Mind sharing the manual with me? Mine does not mention DMA channels for > UART7-10. If you are able to test 7+8 (and it works) could you please > make patch which with for the remaining four devices? Well the file I have is called AM572x_ES1.1_NDA_TRM_vT.pdf, so I am not sure who I am allowed to share that file with. Might be simpler to just ask TI for the latest version. How I hate NDAs. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe 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 11/13] arm: dts: dra7: add DMA properties for UART
On Mon, Sep 29, 2014 at 08:06:47PM +0200, Sebastian Andrzej Siewior wrote:
> Cc: devicet...@vger.kernel.org
> Reviewed-by: Tony Lindgren
> Tested-by: Tony Lindgren
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> arch/arm/boot/dts/dra7.dtsi | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index d678152db4cb..f273e3811f75 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -332,6 +332,8 @@
> ti,hwmods = "uart1";
> clock-frequency = <4800>;
> status = "disabled";
> + dmas = <&sdma 49>, <&sdma 50>;
> + dma-names = "tx", "rx";
> };
>
> uart2: serial@4806c000 {
> @@ -341,6 +343,8 @@
> ti,hwmods = "uart2";
> clock-frequency = <4800>;
> status = "disabled";
> + dmas = <&sdma 51>, <&sdma 52>;
> + dma-names = "tx", "rx";
> };
>
> uart3: serial@4802 {
> @@ -350,6 +354,8 @@
> ti,hwmods = "uart3";
> clock-frequency = <4800>;
> status = "disabled";
> + dmas = <&sdma 53>, <&sdma 54>;
> + dma-names = "tx", "rx";
> };
>
> uart4: serial@4806e000 {
> @@ -359,6 +365,8 @@
> ti,hwmods = "uart4";
> clock-frequency = <4800>;
> status = "disabled";
> + dmas = <&sdma 55>, <&sdma 56>;
> + dma-names = "tx", "rx";
> };
>
> uart5: serial@48066000 {
> @@ -368,6 +376,8 @@
> ti,hwmods = "uart5";
> clock-frequency = <4800>;
> status = "disabled";
> + dmas = <&sdma 63>, <&sdma 64>;
> + dma-names = "tx", "rx";
> };
>
> uart6: serial@48068000 {
> @@ -377,6 +387,8 @@
> ti,hwmods = "uart6";
> clock-frequency = <4800>;
> status = "disabled";
> + dmas = <&sdma 79>, <&sdma 80>;
> + dma-names = "tx", "rx";
> };
>
> uart7: serial@4842 {
According to the manual the DMA channels for UART7 to 10 are:
uart7: 144 145
uart8: 146 147
uart9: 148 149
uart10: 150 151
Might as well add those too. We have uart 7 and 8 in use on our board
so I am about to go test it.
--
Len Sorensen
--
To unsubscribe from this list: send the line "unsubscribe 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 11/13] arm: dts: dra7: add DMA properties for UART
On 11/04/2014 06:02 PM, Lennart Sorensen wrote: > > According to the manual the DMA channels for UART7 to 10 are: > > uart7: 144 145 > uart8: 146 147 > uart9: 148 149 > uart10: 150 151 > > Might as well add those too. We have uart 7 and 8 in use on our board > so I am about to go test it. Mind sharing the manual with me? Mine does not mention DMA channels for UART7-10. If you are able to test 7+8 (and it works) could you please make patch which with for the remaining four devices? Sebastian -- To unsubscribe from this list: send the line "unsubscribe 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] MAINTAINERS: add more files under OMAP SUPPORT
* Felipe Balbi [141103 16:43]: > On Mon, Nov 03, 2014 at 06:32:53PM -0600, Felipe Balbi wrote: > > These files are very important to the healt > > of the OMAP architecture, specially when it > > comes to PM support which currently we have > > working for at least OMAP3 and we'd like > > to know about any changes being made to our > > PMICs and IRQ controllers. > > > > Signed-off-by: Felipe Balbi > > --- > > I wonder if we should list file-by-file since some of hte tps devices > are rather used by NVidia and other SoCs. > > If you prefer, I'll go grep around on our DTS files and list one-by-one, > no issues. Yes probably a good idea to cut down the email traffic a bit. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] ARM: dts: TI: Add CAN support
* Roger Quadros [141104 02:50]: > Hi Tony, > > These patches add CAN support for am33xx, am43xx and dra7 platforms. > They must go in together with CAN driver RAMINIT Syscon support [1]. Can you make this series not depend on [1] for most part without breaking existing functionality? Then we can do a single follow-up patch to enable things after [1] has been merged. That would remove a dependency between driver changes and .dts changes. Regards, Tony > [1] - CAN driver RAMINIT Syscon support > http://article.gmane.org/gmane.linux.can/6773 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] ARM: OMAP2+: gpmc: Error out if timings fail in gpmc_probe_generic_child()
* Roger Quadros [141104 01:04]: > On 11/04/2014 03:14 AM, Tony Lindgren wrote: > > * Tony Lindgren [141103 16:48]: > >> --- a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi > >> +++ b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi > >> + gpmc,device-width = <1>; > >> + gpmc,burst-length = <4>; > > > > I've left out the gpmc,burst-length as that produces now > > warnings about not being used and does not seem to work if > > enabled. > > OK. Seems like it must be used together with either 'gpmc,burst-read' > or/and 'gpmc,burst-write' Yes I did a quick test trying to enable both or one of those, but that won't for smsc911x. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] ARM: OMAP2+: Show bootloader GPMC timings to allow configuring the .dts file
* Roger Quadros [141104 05:41]: > > I don't have any board with smsc or working NOR so I called > gpmc_cs_show_timings() after NAND was setup. > > The printed values match closely to the configured values in the DTS. OK thanks for checking. I've checked with smsc91x, smsc911x and 8250 so far so I think we're good to go. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl4030-power: Fix poweroff with PM configuration enabled
* Igor Grinberg [141104 05:22]:
> Hi Tony,
>
> On 11/02/14 20:07, Tony Lindgren wrote:
> > Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset
> > configuration") enabled configuring the PM features for twl4030.
> >
> > This caused poweroff command to fail on devices that have the
> > BCI charger on twl4030 wired, or have power wired for VBUS.
> > Instead of powering off, the device reboots. This is because
> > voltage is detected on charger or VBUS with the default bits
> > enabled for the power transition registers.
> >
> > To fix the issue, let's just clear VBUS and CHG bits as we want
> > poweroff command to keep the system powered off.
>
> What about devices that really need to start once VBUS or CHG is connected?
More handling can be added for some cases. With this patch the
poweron bits will clear to defaults if power is completely removed.
So start-up with VBUS and CHG works in that case.
However, if you have a battery connected, and you poweroff, with
this patch the device won't power up with VBUS or CHG connected.
Note that most battery operated devices are not using the charger
on twl4030 because it has issues charging a completely empty
battery AFAIK. So most battery powered devices have been using an
external USB charger chip that's not affected by this patch.
We could consider exporting a function for the charger driver to
configure the poweron mask. And we could also consider passing a
mask in ti,use_poweroff = 0xff.
> It seems to me that forcing these bits on power off can break that kind of
> devices and these settings should really be board specific.
> What do you think?
There's a patch series for "[RFC,01/16] kernel: Add support for
poweroff handler call chain" that should help with that. For sure
the poweroff handling needs to be board specific as some systems
may need to use a GPIO to shut off a regulator powering something
before powering off the SoC.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
public trm am572x (was Re: Re: [PATCH v2 1/2] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() variants)
On 09/05/2014 01:14 PM, Menon, Nishanth wrote: > On 09/05/2014 01:08 PM, Paul Walmsley wrote: > [...] Just adding to this: public version of AM572x is now available here: http://www.ti.com/lit/spruhz6 -- 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: [PATCH 0/4] extcon: gpio: add DT support
On Tue, Nov 04, 2014 at 11:42:04AM +0530, George Cherian wrote: > Hi Felipe et al. > > Another series was posted by removing the platform support. > https://lkml.org/lkml/2014/10/14/244 > > I guess I forgot to copy linux-omap. you do too many things in patch one. I wonder why you decided to combine three patches in one for that series. -- balbi signature.asc Description: Digital signature
Re: [PATCH 06/10] ARM: OMAP2+: Show bootloader GPMC timings to allow configuring the .dts file
On 10/30/2014 06:30 PM, Tony Lindgren wrote:
> * Roger Quadros [141030 08:05]:
>> On 10/30/2014 04:45 PM, Tony Lindgren wrote:
>>> * Roger Quadros [141030 07:21]:
On 10/30/2014 02:29 AM, Tony Lindgren wrote:
> +static void gpmc_cs_show_timings(int cs, const char *desc)
> +{
> + gpmc_show_regs(cs, desc);
> +
> + pr_info("gpmc cs%i access configuration:\n", cs);
> + GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 4, 4, "time-para-granularity");
> + GPMC_GET_RAW(GPMC_CS_CONFIG1, 8, 9, "mux-add-data");
> + GPMC_GET_RAW(GPMC_CS_CONFIG1, 12, 13, "device-width");
> + GPMC_GET_RAW(GPMC_CS_CONFIG1, 16, 17, "wait-pin");
> + GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 21, 21, "wait-on-write");
> + GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 22, 22, "wait-on-read");
> + GPMC_GET_RAW_SHIFT(GPMC_CS_CONFIG1, 23, 24, 3, "burst-length");
how does this work with shift = 3?
Possible values of burst length are
0 -> 4
1 -> 8
2 -> 16
>>>
>>> Hmm sounds like a bug..
>
> The shift does not work here for 0 << 3 naturally :) I've changed
> it to l = (shift << l) where shift is 4 in this case.
>
>>> In general, if you a chance to test this patch with a few
>>> devices that would be great. Assuming you have working timings
>>> in the bootloader, just remove the gpmc,* entries temporarily
>>> from the .dts file for a device, and see if the values printed
>>> by this patch make sense. I've used this to generate the values
>>> for the 2430sdp smc91x and zoom 8250 but I don't think I've tried
>>> anything with a burst mode so far.
>>
>> OK. I'll give it a spin with u-boot configured devices.
>
> Great thanks. Updated patch below.
>
> Regards,
>
> Tony
>
>
> 8<
> From: Tony Lindgren
> Date: Wed, 29 Oct 2014 17:16:48 -0700
> Subject: [PATCH] ARM: OMAP2+: Show bootloader GPMC timings to allow
> configuring the .dts file
>
> As we still have some devices with GPMC timings missing from the
> .dts files, let's make it a bit easier to use the bootloader
> values and print them out.
>
> Note that we now need to move the parsing of the device tree provided
> configuration a bit earlier so we can use that for checking if anything
> was configured.
>
> Cc: Roger Quadros
> Signed-off-by: Tony Lindgren
>
I don't have any board with smsc or working NOR so I called
gpmc_cs_show_timings() after NAND was setup.
The printed values match closely to the configured values in the DTS.
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
Re: [PATCH] mfd: twl4030-power: Fix poweroff with PM configuration enabled
Hi Tony,
On 11/02/14 20:07, Tony Lindgren wrote:
> Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset
> configuration") enabled configuring the PM features for twl4030.
>
> This caused poweroff command to fail on devices that have the
> BCI charger on twl4030 wired, or have power wired for VBUS.
> Instead of powering off, the device reboots. This is because
> voltage is detected on charger or VBUS with the default bits
> enabled for the power transition registers.
>
> To fix the issue, let's just clear VBUS and CHG bits as we want
> poweroff command to keep the system powered off.
What about devices that really need to start once VBUS or CHG is connected?
It seems to me that forcing these bits on power off can break that kind of
devices and these settings should really be board specific.
What do you think?
>
> Fixes: e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset configuration")
> Cc: sta...@vger.kernel.org # v3.16+
> Reported-by: Russell King
> Signed-off-by: Tony Lindgren
>
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -44,6 +44,15 @@ static u8 twl4030_start_script_address = 0x2b;
> #define PWR_DEVSLP BIT(1)
> #define PWR_DEVOFF BIT(0)
>
> +/* Register bits for CFG_P1_TRANSITION (also for P2 and P3) */
> +#define STARTON_SWBUGBIT(7) /* Start on watchdog */
> +#define STARTON_VBUS BIT(5) /* Start on VBUS */
> +#define STARTON_VBAT BIT(4) /* Start on battery insert */
> +#define STARTON_RTC BIT(3) /* Start on RTC */
> +#define STARTON_USB BIT(2) /* Start on USB host */
> +#define STARTON_CHG BIT(1) /* Start on charger */
> +#define STARTON_PWON BIT(0) /* Start on PWRON button */
> +
> #define SEQ_OFFSYNC (1 << 0)
>
> #define PHY_TO_OFF_PM_MASTER(p) (p - 0x36)
> @@ -606,6 +615,44 @@ twl4030_power_configure_resources(const struct
> twl4030_power_data *pdata)
> return 0;
> }
>
> +static int twl4030_starton_mask_and_set(u8 bitmask, u8 bitvalues)
> +{
> + u8 regs[3] = { TWL4030_PM_MASTER_CFG_P1_TRANSITION,
> +TWL4030_PM_MASTER_CFG_P2_TRANSITION,
> +TWL4030_PM_MASTER_CFG_P3_TRANSITION, };
> + u8 val;
> + int i, err;
> +
> + err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, TWL4030_PM_MASTER_KEY_CFG1,
> +TWL4030_PM_MASTER_PROTECT_KEY);
> + if (err)
> + goto relock;
> + err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER,
> +TWL4030_PM_MASTER_KEY_CFG2,
> +TWL4030_PM_MASTER_PROTECT_KEY);
> + if (err)
> + goto relock;
> +
> + for (i = 0; i < sizeof(regs); i++) {
> + err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER,
> + &val, regs[i]);
> + if (err)
> + break;
> + val = (~bitmask & val) | (bitmask & bitvalues);
> + err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER,
> +val, regs[i]);
> + if (err)
> + break;
> + }
> +
> + if (err)
> + pr_err("TWL4030 Register access failed: %i\n", err);
> +
> +relock:
> + return twl_i2c_write_u8(TWL_MODULE_PM_MASTER, 0,
> + TWL4030_PM_MASTER_PROTECT_KEY);
> +}
> +
> /*
> * In master mode, start the power off sequence.
> * After a successful execution, TWL shuts down the power to the SoC
> @@ -615,6 +662,11 @@ void twl4030_power_off(void)
> {
> int err;
>
> + /* Disable start on charger or VBUS as it can break poweroff */
> + err = twl4030_starton_mask_and_set(STARTON_VBUS | STARTON_CHG, 0);
> + if (err)
> + pr_err("TWL4030 Unable to configure start-up\n");
> +
> err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, PWR_DEVOFF,
> TWL4030_PM_MASTER_P1_SW_EVENTS);
> if (err)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Touchscreen performance related fixes
On 11/04/2014 12:44 PM, Vignesh R wrote: > I ran following commands > $ evtest /dev/input/touchscreen0 & > (with heavy item on touchscreen) > and > $ cat /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage4_en > (in a busy loop) > I tried above experiment on my board but I didn't hit any problem even > after running for close to 30 minutes. I was unable to reproduce failure Just to make sure: You had the touchscreen and iio command running in parallel and you saw evtest output while there was iio operation? > The problem may be in configuring correct charge-delay value. Please run: > $ ts_test > /dev/null > and let me know if pen events are being detected properly. Well I get the touch events but not while busy loop on iio interface is running (I get maybe one event every 5 seconds or so). After all, it is the same HW you have. Sebastian -- To unsubscribe from this list: send the line "unsubscribe 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/4] Touchscreen performance related fixes
On Monday 03 November 2014 05:47 PM, Sebastian Andrzej Siewior wrote:
> On 10/27/2014 08:02 PM, Griffis, Brad wrote:
>> On 10/27/2014 12:34 PM, Sebastian Andrzej Siewior wrote:
>>> Do we really need #3 (and then #4)? Given the complexity we have already,
>>> is there any benefit by decreasing this value?
>>
>> I specifically requested we add ti,charge-delay to the device tree because
>> it is THE critical value to tune for a given design. Although I think the
>> current value of 0xB000 will be suitable for a great many designs, I expect
>> that many users will need to adjust this value for their hardware. Details
>> such as which touchscreen vendor is being used and how the touchscreen is
>> connected (header vs cable) have an effect on what's appropriate here.
>
> Oh. That is one knob I hoped we could avoid since I haven't seen it
> before on other TSCs. But okay. Please make sure that there is a
> message printed if the default value is used. And lets hope the user
> will do something about his.
>
>>> Would someone want to increase it? Can we safely determine a value which
>>> works for everyone?
>>
>> This value represents a hardware delay before checking for the pen-up event.
>> So in the scenario where someone is seeing excessive false pen-up events
>> they will want to increase this parameter. The downsize of making this
>> larger is that it decreases the overall sampling speed of both the
>> touchscreen as well as the standalone ADC samples. At one point I tried
>> making it huge, but that made the touchscreen overly sluggish because the
>> sampling became too slow. So there is a definite trade-off that if you make
>> it too large the touchscreen becomes sluggish, and if you make it too small
>> then you may see false pen-up events. The optimal value will need to be
>> tuned for a given design.
>
> I applied the patches from this series and did the following test on my
> am335x-evm: A mug on the touchscreen (to make sure the events are
> coming), evtest on the event node to see that the events and loop of
>
> cat /sys/bus/iio/devices/iio\:device0/in_voltage4_raw
>
> In the past I was able lock up the TSC/ADC HW that way (see commit
> 7ca6740cd1 ("mfd: input: iio: ti_amm335x: Rework TSC/ADC
> synchronization")) for details.
> With this patches applied I don't seen any TSC events once the IIO
> interface is (heavily) used. Can this be fixed?
I ran following commands
$ evtest /dev/input/touchscreen0 &
(with heavy item on touchscreen)
and
$ cat /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage4_en
(in a busy loop)
I tried above experiment on my board but I didn't hit any problem even
after running for close to 30 minutes. I was unable to reproduce failure
The problem may be in configuring correct charge-delay value. Please run:
$ ts_test > /dev/null
and let me know if pen events are being detected properly.
>
> Sebastian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] ARM: OMAP2+: hwmod: AM335x/AM43x: Move am33xx_l4_hs_hwmod to ipblock_data
This patch moves am33xx_l4_hs_hwmod from 33xx_data to ipblock_data. This
is required because it can be reused in 43xx to add hwmod support to
tscadc as it uses the same l4_hs hwmod in am43xx. This helps in setting
appropriate clock domain names for tscadc on am33xx and am43xx.
Signed-off-by: Vignesh R
---
arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 1 +
arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 15 +++
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 15 ---
3 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
index 130332c0534d..6e57b8ad0db5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
@@ -82,6 +82,7 @@ extern struct omap_hwmod am33xx_l3_main_hwmod;
extern struct omap_hwmod am33xx_l3_s_hwmod;
extern struct omap_hwmod am33xx_l3_instr_hwmod;
extern struct omap_hwmod am33xx_l4_ls_hwmod;
+extern struct omap_hwmod am33xx_l4_hs_hwmod;
extern struct omap_hwmod am33xx_l4_wkup_hwmod;
extern struct omap_hwmod am33xx_mpu_hwmod;
extern struct omap_hwmod am33xx_pruss_hwmod;
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index a579b89ce9b7..7f44922ab540 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -94,6 +94,21 @@ struct omap_hwmod am33xx_l4_ls_hwmod = {
},
};
+/* l4_hs */
+struct omap_hwmod am33xx_l4_hs_hwmod = {
+ .name = "l4_hs",
+ .class = &am33xx_l4_hwmod_class,
+ .clkdm_name = "l4hs_clkdm",
+ .flags = HWMOD_INIT_NO_IDLE,
+ .main_clk = "l4hs_gclk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_L4HS_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/* l4_wkup */
struct omap_hwmod am33xx_l4_wkup_hwmod = {
.name = "l4_wkup",
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 6b406ca4bd3b..ce7d260495cb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -63,21 +63,6 @@ static struct omap_hwmod am33xx_emif_hwmod = {
},
};
-/* l4_hs */
-static struct omap_hwmod am33xx_l4_hs_hwmod = {
- .name = "l4_hs",
- .class = &am33xx_l4_hwmod_class,
- .clkdm_name = "l4hs_clkdm",
- .flags = HWMOD_INIT_NO_IDLE,
- .main_clk = "l4hs_gclk",
- .prcm = {
- .omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_L4HS_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
static struct omap_hwmod_rst_info am33xx_wkup_m3_resets[] = {
{ .name = "wkup_m3", .rst_shift = 3, .st_shift = 5 },
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] ARM: OMAP2+: hwmod: AM335x/AM43x: add hwmod support for tscadc on am43x-evm
This patch adds hwmod support for tscadc to work on am43xx-evm. The am33xx
hwmod structures of tscadc has been moved to ipblock_data so that it can
be reused in am43xx. The clock domain names are separately set for am33xx
and am43xx. Thus tscadc dt entries can now be added to am43xx board
dt files.
Signed-off-by: Vignesh R
---
.../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 1 +
.../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 56 ++
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 49 ---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
4 files changed, 58 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
index 6e57b8ad0db5..b92a7c7825fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
@@ -65,6 +65,7 @@ extern struct omap_hwmod_ocp_if am33xx_l4_ls__timer4;
extern struct omap_hwmod_ocp_if am33xx_l4_ls__timer5;
extern struct omap_hwmod_ocp_if am33xx_l4_ls__timer6;
extern struct omap_hwmod_ocp_if am33xx_l4_ls__timer7;
+extern struct omap_hwmod_ocp_if am33xx_l4_wkup__adc_tsc;
extern struct omap_hwmod_ocp_if am33xx_l3_main__tpcc;
extern struct omap_hwmod_ocp_if am33xx_l3_main__tptc0;
extern struct omap_hwmod_ocp_if am33xx_l3_main__tptc1;
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 7f44922ab540..ce9c133ea9ff 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -29,6 +29,7 @@
#define CLKCTRL(oh, clkctrl) ((oh).prcm.omap4.clkctrl_offs = (clkctrl))
#define RSTCTRL(oh, rstctrl) ((oh).prcm.omap4.rstctrl_offs = (rstctrl))
#define RSTST(oh, rstst) ((oh).prcm.omap4.rstst_offs = (rstst))
+#define CLKDMNAME(oh, clkdmname) ((oh).clkdm_name = (clkdmname))
/*
* 'l3' class
@@ -151,6 +152,45 @@ struct omap_hwmod_class am33xx_wkup_m3_hwmod_class = {
};
/*
+ * 'adc/tsc' class
+ * TouchScreen Controller (Anolog-To-Digital Converter)
+ */
+static struct omap_hwmod_class_sysconfig am33xx_adc_tsc_sysc = {
+ .rev_offs = 0x00,
+ .sysc_offs = 0x10,
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class am33xx_adc_tsc_hwmod_class = {
+ .name = "adc_tsc",
+ .sysc = &am33xx_adc_tsc_sysc,
+};
+
+struct omap_hwmod am33xx_adc_tsc_hwmod = {
+ .name = "adc_tsc",
+ .class = &am33xx_adc_tsc_hwmod_class,
+ .clkdm_name = "l4_wkup_clkdm",
+ .main_clk = "adc_tsc_fck",
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* L4 WKUP -> ADC_TSC */
+
+struct omap_hwmod_ocp_if am33xx_l4_wkup__adc_tsc = {
+ .master = &am33xx_l4_wkup_hwmod,
+ .slave = &am33xx_adc_tsc_hwmod,
+ .clk= "dpll_core_m4_div2_ck",
+ .user = OCP_USER_MPU,
+};
+
+/*
* 'pru-icss' class
* Programmable Real-Time Unit and Industrial Communication Subsystem
*/
@@ -1370,6 +1410,7 @@ static void omap_hwmod_am33xx_clkctrl(void)
CLKCTRL(am33xx_timer5_hwmod, AM33XX_CM_PER_TIMER5_CLKCTRL_OFFSET);
CLKCTRL(am33xx_timer6_hwmod, AM33XX_CM_PER_TIMER6_CLKCTRL_OFFSET);
CLKCTRL(am33xx_timer7_hwmod, AM33XX_CM_PER_TIMER7_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_adc_tsc_hwmod, AM33XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET);
CLKCTRL(am33xx_smartreflex0_hwmod,
AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET);
CLKCTRL(am33xx_smartreflex1_hwmod,
@@ -1398,6 +1439,18 @@ static void omap_hwmod_am33xx_clkctrl(void)
CLKCTRL(am33xx_aes0_hwmod , AM33XX_CM_PER_AES0_CLKCTRL_OFFSET);
}
+static void am33xx_hwmod_clockdomain(void)
+{
+ CLKDMNAME(am33xx_l4_hs_hwmod, "l4hs_clkdm");
+ CLKDMNAME(am33xx_adc_tsc_hwmod, "l4_wkup_clkdm");
+}
+
+static void am43xx_hwmod_clockdomain(void)
+{
+ CLKDMNAME(am33xx_l4_hs_hwmod, "l3_clkdm");
+ CLKDMNAME(am33xx_adc_tsc_hwmod, "l3s_tsc_clkdm");
+}
+
static void omap_hwmod_am33xx_rst(void)
{
RSTCTRL(am33xx_pruss_hwmod, AM33XX_RM_PER_RSTCTRL_OFFSET);
@@ -1409,6 +1462,7 @@ void omap_hwmod_am33xx_reg(void)
{
omap_hwmod_am33xx_clkctrl();
omap_hwmod_am33xx_rst();
+ am33xx_hwmod_clockdomain();
}
static void omap_hwmod_am43xx_clkctrl(void)
@@ -1443,6 +1497,7 @@ static void omap_hwmod_am43xx_clkctrl(void)
CLKCTRL(am33xx_timer5_hwmod, AM43XX_CM_PER_TIMER5_CLKCTRL_OFFSET);
CLKCTRL(am33xx_timer6_hwmod, AM43XX_CM_PER_TIMER6_CLKCTRL_OFFSET);
CLKCTRL(am33xx_timer7_hwmod, AM43XX_
[PATCH v2 3/3] ARM: dts: AM43xx: add tscadc DT entries for am437x-evm and am43x-epos-evm
This patch adds tscadc DT entries for am437x-gp-evm and am43x-epos-evm.
Signed-off-by: Vignesh R
---
arch/arm/boot/dts/am4372.dtsi| 20
arch/arm/boot/dts/am437x-gp-evm.dts | 8
arch/arm/boot/dts/am43x-epos-evm.dts | 8
3 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 46660ffd2b65..cb73e5eb6971 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -667,6 +667,26 @@
};
};
+ tscadc: tscadc@44e0d000 {
+ compatible = "ti,am3359-tscadc";
+ reg = <0x44e0d000 0x1000>;
+ ti,hwmods = "adc_tsc";
+ interrupts = ;
+ clocks = <&adc_tsc_fck>;
+ clock-names = "fck";
+ status = "disabled";
+
+ tsc {
+ compatible = "ti,am3359-tsc";
+ };
+
+ adc {
+ #io-channel-cells = <1>;
+ compatible = "ti,am3359-adc";
+ };
+
+ };
+
sham: sham@5310 {
compatible = "ti,omap5-sham";
ti,hwmods = "sham";
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index e7ac47fa6615..2ffd6d6dcc87 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -343,6 +343,14 @@
status = "okay";
};
+&tscadc {
+ status = "okay";
+
+ adc {
+ ti,adc-channels = <0 1 2 3 4 5 6 7>;
+ };
+};
+
&ecap0 {
status = "okay";
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index ac3e4859935f..f9bc607f3b3a 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -519,6 +519,14 @@
status = "okay";
};
+&tscadc {
+ status = "okay";
+
+ adc {
+ ti,adc-channels = <0 1 2 3 4 5 6 7>;
+ };
+};
+
&ecap0 {
status = "okay";
pinctrl-names = "default";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] arm: boot: dts: am4372: add tscadc DT entries for am437x-evm and am43x-epos-evm
On Friday 31 October 2014 07:16 PM, Nishanth Menon wrote:
> On 13:16-20141031, Vignesh R wrote:
>> This patch adds tscadc DT entries for am437x-gp-evm and am43x-epos-evm.
>>
>> Signed-off-by: Vignesh R
>> ---
>> arch/arm/boot/dts/am4372.dtsi| 20
>> arch/arm/boot/dts/am437x-gp-evm.dts | 8
>> arch/arm/boot/dts/am43x-epos-evm.dts | 8
>
> I personally prefer the soc dt split off from board dt, but others
> prefer this as done here.. no objections either way.
>
>> 3 files changed, 36 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>> index 46660ffd2b65..fd2de8f256e6 100644
>> --- a/arch/arm/boot/dts/am4372.dtsi
>> +++ b/arch/arm/boot/dts/am4372.dtsi
>> @@ -667,6 +667,26 @@
>> };
>> };
>>
>> +tscadc: tscadc@44e0d000 {
>> +compatible = "ti,am4372-tscadc","ti,am3359-tscadc";
> ^^ bindings ?
> $ git grep ti,am4372-tscadc Documentation/devicetree/bindings/
> returns nothing as of 3.18-rc2
>
I will drop unused ti,am4372-tscadc.
>> +reg = <0x44e0d000 0x1000>;
>> +ti,hwmods = "adc_tsc";
>> +interrupts = ;
>> +clocks = <&adc_tsc_fck>;
>> +clock-names = "fck";
>> +status = "disabled";
>> +
>> +tsc {
>> +compatible = "ti,am4372-tsc", "ti,am3359-tsc";
>> +};
>> +
>> +adc {
>> +#io-channel-cells = <1>;
>> +compatible = "ti,am4372-adc", "ti,am3359-adc";
>> +};
>> +
>> +};
>> +
>> sham: sham@5310 {
>> compatible = "ti,omap5-sham";
>> ti,hwmods = "sham";
>> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
>> b/arch/arm/boot/dts/am437x-gp-evm.dts
>> index e7ac47fa6615..2ffd6d6dcc87 100644
>> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
>> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
>> @@ -343,6 +343,14 @@
>> status = "okay";
>> };
>>
>> +&tscadc {
>> +status = "okay";
>> +
>> +adc {
>> +ti,adc-channels = <0 1 2 3 4 5 6 7>;
>> +};
>> +};
>> +
>> &ecap0 {
>> status = "okay";
>> pinctrl-names = "default";
>> diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
>> b/arch/arm/boot/dts/am43x-epos-evm.dts
>> index ac3e4859935f..f9bc607f3b3a 100644
>> --- a/arch/arm/boot/dts/am43x-epos-evm.dts
>> +++ b/arch/arm/boot/dts/am43x-epos-evm.dts
>> @@ -519,6 +519,14 @@
>> status = "okay";
>> };
>>
>> +&tscadc {
>> +status = "okay";
>> +
>> +adc {
>> +ti,adc-channels = <0 1 2 3 4 5 6 7>;
>> +};
>> +};
>> +
>> &ecap0 {
>> status = "okay";
>> pinctrl-names = "default";
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Add support for ADC on am437x-gp and am43x-epos-evm
This series of patches enable ADC on am437x-gp-evm and am43x-epos-evm. The ADC clock hwmod data of am33xx has been moved to commom place so that both am43xx and am33xx can reuse them. tscadc DT node has been adided to am437x-gp and am43x-epos dt files. With these patches, ADC functionalities are now available on am43xx. Changelog: v2: Removed phy addresses in hwmod. Using DT instead. Removed unused "ti,am4372" compatible string. Use macro to set clk domain name. Fixed subject format of all patches Vignesh R (3): ARM: OMAP2+: hwmod: AM335x/AM43x: Move am33xx_l4_hs_hwmod to ipblock_data ARM: OMAP2+: hwmod: AM335x/AM43x: add hwmod support for tscadc on am43x-evm ARM: dts: AM43xx: add tscadc DT entries for am437x-evm and am43x-epos-evm arch/arm/boot/dts/am4372.dtsi | 20 ++ arch/arm/boot/dts/am437x-gp-evm.dts| 8 +++ arch/arm/boot/dts/am43x-epos-evm.dts | 8 +++ .../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 2 + .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 71 ++ arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 64 --- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 + 7 files changed, 110 insertions(+), 64 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] arm: mach-omap2: omap_hwmod_43xx_data: add hwmod support for tscadc on am43x-evm
On Friday 31 October 2014 07:14 PM, Nishanth Menon wrote:
> On 13:16-20141031, Vignesh R wrote:
>> This patch adds hwmod support for tscadc to work on am43xx-evm. The am33xx
>> hwmod structures of tscadc has been moved to ipblock_data so that it can
>> be reused in am43xx. The clock domain names are separately set for am33xx
>> and am43xx. Thus tscadc dt entries can now be added to am43xx board
>> dt files.
>>
>> Signed-off-by: Vignesh R
>> ---
>> .../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 1 +
>> .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 64
>> ++
>> arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 49 -
>> arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
>> 4 files changed, 66 insertions(+), 49 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
>> b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
>> index 6e57b8ad0db5..b92a7c7825fa 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
>> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
>> @@ -65,6 +65,7 @@ extern struct omap_hwmod_ocp_if am33xx_l4_ls__timer4;
>> extern struct omap_hwmod_ocp_if am33xx_l4_ls__timer5;
>> extern struct omap_hwmod_ocp_if am33xx_l4_ls__timer6;
>> extern struct omap_hwmod_ocp_if am33xx_l4_ls__timer7;
>> +extern struct omap_hwmod_ocp_if am33xx_l4_wkup__adc_tsc;
>> extern struct omap_hwmod_ocp_if am33xx_l3_main__tpcc;
>> extern struct omap_hwmod_ocp_if am33xx_l3_main__tptc0;
>> extern struct omap_hwmod_ocp_if am33xx_l3_main__tptc1;
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
>> index 7f44922ab540..ef14e56a3968 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
>> @@ -151,6 +151,54 @@ struct omap_hwmod_class am33xx_wkup_m3_hwmod_class = {
>> };
>>
>> /*
>> + * 'adc/tsc' class
>> + * TouchScreen Controller (Anolog-To-Digital Converter)
>> + */
>> +static struct omap_hwmod_class_sysconfig am33xx_adc_tsc_sysc = {
>> +.rev_offs = 0x00,
>> +.sysc_offs = 0x10,
>> +.sysc_flags = SYSC_HAS_SIDLEMODE,
>> +.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
>> +SIDLE_SMART_WKUP),
>> +.sysc_fields= &omap_hwmod_sysc_type2,
>> +};
>> +
>> +static struct omap_hwmod_class am33xx_adc_tsc_hwmod_class = {
>> +.name = "adc_tsc",
>> +.sysc = &am33xx_adc_tsc_sysc,
>> +};
>> +
>> +struct omap_hwmod am33xx_adc_tsc_hwmod = {
>> +.name = "adc_tsc",
>> +.class = &am33xx_adc_tsc_hwmod_class,
>> +.clkdm_name = "l4_wkup_clkdm",
>> +.main_clk = "adc_tsc_fck",
>> +.prcm = {
>> +.omap4 = {
>> +.modulemode = MODULEMODE_SWCTRL,
>> +},
>> +},
>> +};
>> +
>> +/* L4 WKUP -> ADC_TSC */
>> +static struct omap_hwmod_addr_space am33xx_adc_tsc_addrs[] = {
>> +{
>> +.pa_start = 0x44E0D000,
>> +.pa_end = 0x44E0D000 + SZ_8K - 1,
>> +.flags = ADDR_TYPE_RT
>> +},
>> +{ }
>> +};
>
> NAK. we dont want to see phy addresses in hwmod anymore. please add that
> to DT. I suggest doing that clean up prior to this patch.
>
Will drop this and pass address from DT
>> +
>> +struct omap_hwmod_ocp_if am33xx_l4_wkup__adc_tsc = {
>> +.master = &am33xx_l4_wkup_hwmod,
>> +.slave = &am33xx_adc_tsc_hwmod,
>> +.clk= "dpll_core_m4_div2_ck",
>> +.addr = am33xx_adc_tsc_addrs,
>> +.user = OCP_USER_MPU,
>> +};
>> +
>> +/*
>> * 'pru-icss' class
>> * Programmable Real-Time Unit and Industrial Communication Subsystem
>> */
>> @@ -1370,6 +1418,7 @@ static void omap_hwmod_am33xx_clkctrl(void)
>> CLKCTRL(am33xx_timer5_hwmod, AM33XX_CM_PER_TIMER5_CLKCTRL_OFFSET);
>> CLKCTRL(am33xx_timer6_hwmod, AM33XX_CM_PER_TIMER6_CLKCTRL_OFFSET);
>> CLKCTRL(am33xx_timer7_hwmod, AM33XX_CM_PER_TIMER7_CLKCTRL_OFFSET);
>> +CLKCTRL(am33xx_adc_tsc_hwmod, AM33XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET);
>> CLKCTRL(am33xx_smartreflex0_hwmod,
>> AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET);
>> CLKCTRL(am33xx_smartreflex1_hwmod,
>> @@ -1398,6 +1447,18 @@ static void omap_hwmod_am33xx_clkctrl(void)
>> CLKCTRL(am33xx_aes0_hwmod , AM33XX_CM_PER_AES0_CLKCTRL_OFFSET);
>> }
>>
>> +static void am33xx_hwmod_clockdomain(void)
>> +{
>> +am33xx_l4_hs_hwmod.clkdm_name = "l4hs_clkdm";
>> +am33xx_adc_tsc_hwmod.clkdm_name = "l4_wkup_clkdm";
>> +}
>> +
>> +static void am43xx_hwmod_clockdomain(void)
>> +{
>> +am33xx_l4_hs_hwmod.clkdm_name = "l3_clkdm";
>> +am33xx_adc_tsc_hwmod.clkdm_name = "l3s_tsc_clkdm";
>> +}
>> +
>
> maybe do something similar to CLKCTRL macro?
>
OK, I will create a macro for clkdm_name.
>> st
[PATCH v3 08/10] ARM: dts: am33xx: Add control module syscon node
Use syscon regmap to expose the Control module register space.
This register space is shared between many users e.g. DCAN, USB, display, etc.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/am33xx.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 8318105..9f3058c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -83,6 +83,11 @@
};
};
+ am33xx_control_module: control_module@4a002000 {
+ compatible = "syscon";
+ reg = <0x44e1 0x7fc>;
+ };
+
am33xx_pinmux: pinmux@44e10800 {
compatible = "pinctrl-single";
reg = <0x44e10800 0x0238>;
--
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 v3 05/10] ARM: dts: am4372: Add control module syscon node
Use syscon regmap to expose the Control module register space.
This register space is shared between many users e.g. DCAN, USB, display, etc.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/am4372.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 46660ff..899c57c 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -57,6 +57,11 @@
cache-level = <2>;
};
+ am43xx_control_module: control_module@4a002000 {
+ compatible = "syscon";
+ reg = <0x44e1 0x7f4>;
+ };
+
am43xx_pinmux: pinmux@44e10800 {
compatible = "ti,am437-padconf", "pinctrl-single";
reg = <0x44e10800 0x31c>;
--
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 v3 06/10] ARM: dts: am4372: Add DCAN nodes
The SoC contains 2 DCAN modules. Add them.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 899c57c..98f81c9 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -901,6 +901,28 @@
compatible = "mmio-sram";
reg = <0x4030 0x4>; /* 256k */
};
+
+ dcan0: can@481cc000 {
+ compatible = "ti,am3352-d_can0";
+ ti,hwmods = "d_can0";
+ clocks = <&dcan0_fck>;
+ clock-names = "fck";
+ reg = <0x481cc000 0x2000>;
+ syscon-raminit = <&am43xx_control_module 0x644>;
+ interrupts = ;
+ status = "disabled";
+ };
+
+ dcan1: can@481d {
+ compatible = "ti,am3352-d_can1";
+ ti,hwmods = "d_can1";
+ clocks = <&dcan1_fck>;
+ clock-names = "fck";
+ reg = <0x481d 0x2000>;
+ syscon-raminit = <&am43xx_control_module 0x644>;
+ interrupts = ;
+ status = "disabled";
+ };
};
};
--
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 v3 07/10] arm: dts: am437x-gp: Add dcan support
From: Mugunthan V N
Add DCAN support for AM437x GP EVM with both DCAN instances.
[Roger Q] Updated output pin to not use pull up.
Signed-off-by: Mugunthan V N
Signed-off-by: George Cherian
Signed-off-by: Sekhar Nori
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/am437x-gp-evm.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index e7ac47f..58594fd 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -254,6 +254,20 @@
0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
>;
};
+
+ dcan0_default: dcan0_default_pins {
+ pinctrl-single,pins = <
+ 0x178 (PIN_OUTPUT | MUX_MODE2) /*
uart1_ctsn.d_can0_tx */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE2)/*
uart1_rtsn.d_can0_rx */
+ >;
+ };
+
+ dcan1_default: dcan1_default_pins {
+ pinctrl-single,pins = <
+ 0x180 (PIN_OUTPUT | MUX_MODE2) /*
uart1_rxd.d_can1_tx */
+ 0x184 (PIN_INPUT_PULLUP | MUX_MODE2)/*
uart1_txd.d_can1_rx */
+ >;
+ };
};
&i2c0 {
@@ -511,3 +525,15 @@
};
};
};
+
+&dcan0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dcan0_default>;
+ status = "okay";
+};
+
+&dcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dcan1_default>;
+ status = "okay";
+};
--
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 v3 10/10] ARM: dts: am335x-evm: Add DCAN1 details
DCAN1 is routed to CAN port (J11) when Profile 1 is selected on the
profile selection switch.
Provide information for DCAN1 pins and node but keep it disabled
by default. User has to manually enable it if Profile 1 is chosen.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/am335x-evm.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e2156a5..7b7bd8f 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -307,6 +307,13 @@
0x144 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
rmii1_ref_clk.mcasp1_axr3 */
>;
};
+
+ dcan1_pins_default: dcan1_pins_default {
+ pinctrl-single,pins = <
+ 0x168 (PIN_OUTPUT | MUX_MODE2) /* uart0_ctsn.d_can1_tx
*/
+ 0x16c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
uart0_rtsn.d_can1_rx */
+ >;
+ };
};
&uart0 {
@@ -664,3 +671,9 @@
&aes {
status = "okay";
};
+
+&dcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dcan1_pins_default>;
+ status = "disabled";/* Enable only if Profile 1 is selected */
+};
--
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 v3 09/10] ARM: dts: am33xx: Update DCAN nodes
Add "raminit-syscon" property to specify the RAMINIT register.
Add clock information.
Rename can nodes from "d_can" to "can" to be compliant
with the ePAPR specs.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/am33xx.dtsi | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9f3058c..f227ba1 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -338,20 +338,24 @@
interrupts = <91>;
};
- dcan0: d_can@481cc000 {
- compatible = "bosch,d_can";
+ dcan0: can@481cc000 {
+ compatible = "ti,am3352-d_can0";
ti,hwmods = "d_can0";
- reg = <0x481cc000 0x2000
- 0x44e10644 0x4>;
+ reg = <0x481cc000 0x2000>;
+ clocks = <&dcan0_fck>;
+ clock-names = "fck";
+ syscon-raminitn = <&am33xx_control_module 0x644>;
interrupts = <52>;
status = "disabled";
};
- dcan1: d_can@481d {
- compatible = "bosch,d_can";
+ dcan1: can@481d {
+ compatible = "ti,am3352-d_can1";
ti,hwmods = "d_can1";
- reg = <0x481d 0x2000
- 0x44e10644 0x4>;
+ reg = <0x481d 0x2000>;
+ clocks = <&dcan1_fck>;
+ clock-names = "fck";
+ syscon-raminit = <&am33xx_control_module 0x644>;
interrupts = <55>;
status = "disabled";
};
--
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 v3 03/10] ARM: dts: dra7-evm: Add CAN support
The board has 2 CAN ports but only the first one can be used.
Enable the first CAN port.
WAKEUP0 pin doesn't have INPUT enable bit so we just disable
weak PULLs.
The second CAN port cannot be used without hardware modification
so we don't enable the second port.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/dra7-evm.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index c6ce625..8c2c37b 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -171,6 +171,22 @@
0xd0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
>;
};
+
+ dcan1_pins_default: dcan1_pins_default {
+ pinctrl-single,pins = <
+ 0x3d0 (PIN_OUTPUT | MUX_MODE0) /* dcan1_tx */
+ 0x3d4 (MUX_MODE15)/* dcan1_rx.off */
+ 0x418 (PULL_DIS | MUX_MODE1) /* wakeup0.dcan1_rx */
+ >;
+ };
+
+ dcan1_pins_sleep: dcan1_pins_sleep {
+ pinctrl-single,pins = <
+ 0x3d0 (MUX_MODE15)/* dcan1_tx.off */
+ 0x3d4 (MUX_MODE15)/* dcan1_rx.off */
+ 0x418 (MUX_MODE15)/* wakeup0.off */
+ >;
+ };
};
&i2c1 {
@@ -528,3 +544,10 @@
ti,no-reset-on-init;
ti,no-idle-on-init;
};
+
+&dcan1 {
+ status = "ok";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&dcan1_pins_default>;
+ pinctrl-1 = <&dcan1_pins_sleep>;
+};
--
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 v3 00/10] ARM: dts: TI: Add CAN support
Hi Tony, These patches add CAN support for am33xx, am43xx and dra7 platforms. They must go in together with CAN driver RAMINIT Syscon support [1]. Tested on am335x-evm, am437x-gp-evm and dra7-evm. NOTE: - for DCAN to work on DRA7 we need this patch to keep the CAN PHY powered. https://lkml.org/lkml/2014/10/21/484 - There is another issue which causes undesired behaviour if WKUPAON and L4CFG clock domains are allowed to HW_AUTO. Undesired behaviour is in the form of DCAN1 module being stuck-in-transition when disabled and RAMINIT-done bit not getting set as part of RAMINIT mechanism. To address these issues there is a patch to prevent these clockdomains from HW_AUTO. https://github.com/rogerq/linux/commit/31d6da939dbbaf8ea2ab96ca5680b81cd5607e51 Even without this second patch DCAN seems to work. cheers, -roger Changelog: v3: - Move raminit register data into driver data - rename syscon property to "syscon-raminit" v2: - Added vendor prefix "ti," to raminit properties - Updated am335x dcan nodes [1] - CAN driver RAMINIT Syscon support http://article.gmane.org/gmane.linux.can/6773 cheers, -roger --- Mugunthan V N (1): arm: dts: am437x-gp: Add dcan support Roger Quadros (9): ARM: dts: dra7: Add syscon regmap for CORE CONTROL area ARM: dts: DRA7: Add DCAN nodes ARM: dts: dra7-evm: Add CAN support ARM: dts: dra72-evm: Add CAN support ARM: dts: am4372: Add control module syscon node ARM: dts: am4372: Add DCAN nodes ARM: dts: am33xx: Add control module syscon node ARM: dts: am33xx: Update DCAN nodes ARM: dts: am335x-evm: Add DCAN1 details arch/arm/boot/dts/am335x-evm.dts| 13 + arch/arm/boot/dts/am33xx.dtsi | 25 + arch/arm/boot/dts/am4372.dtsi | 27 +++ arch/arm/boot/dts/am437x-gp-evm.dts | 26 ++ arch/arm/boot/dts/dra7-evm.dts | 23 +++ arch/arm/boot/dts/dra7.dtsi | 27 +++ arch/arm/boot/dts/dra72-evm.dts | 23 +++ 7 files changed, 156 insertions(+), 8 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 v3 02/10] ARM: dts: DRA7: Add DCAN nodes
The SoC supports 2 DCAN nodes. Add them.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/dra7.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5fd52cd..9d84846 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = &uart4;
serial4 = &uart5;
serial5 = &uart6;
+ d_can0 = &dcan1;
+ d_can1 = &dcan2;
};
timer {
@@ -1270,6 +1272,26 @@
ti,irqs-skip = <10 133 139 140>;
ti,irqs-safe-map = <0>;
};
+
+ dcan1: can@481cc000 {
+ compatible = "ti,dra7-d_can1";
+ ti,hwmods = "dcan1";
+ reg = <0x4ae3c000 0x2000>;
+ syscon-raminit = <&dra7_ctrl_core 0x558>;
+ interrupts = ;
+ clocks = <&dcan1_sys_clk_mux>;
+ status = "disabled";
+ };
+
+ dcan2: can@481d {
+ compatible = "ti,dra7-d_can2";
+ ti,hwmods = "dcan2";
+ reg = <0x4848 0x2000>;
+ syscon-raminit = <&dra7_ctrl_core 0x558>;
+ interrupts = ;
+ clocks = <&sys_clkin1>;
+ status = "disabled";
+ };
};
};
--
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 v3 01/10] ARM: dts: dra7: Add syscon regmap for CORE CONTROL area
Display and DCAN drivers use syscon regmap to access some registers
in the CORE control area. Add the syscon regmap node for this
area.
Cc: Tomi Valkeinen
Cc: Nishanth Menon
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/dra7.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..5fd52cd 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -201,6 +201,11 @@
ti,hwmods = "counter_32k";
};
+ dra7_ctrl_core: ctrl_core@4a002000 {
+ compatible = "syscon";
+ reg = <0x4a002000 0x6d0>;
+ };
+
dra7_ctrl_general: tisyscon@4a002e00 {
compatible = "syscon";
reg = <0x4a002e00 0x7c>;
--
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 v3 04/10] ARM: dts: dra72-evm: Add CAN support
The board has 2 CAN ports but only the first one can be used.
Enable the first CAN port.
WAKEUP0 pin doesn't have INPUT enable bit so we just disable
weak PULLs.
The second CAN port cannot be used without hardware modification
so we don't enable the second port.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/dra72-evm.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 4107428..a4b01ce 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -26,6 +26,22 @@
0x404 (PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */
>;
};
+
+ dcan1_pins_default: dcan1_pins_default {
+ pinctrl-single,pins = <
+ 0x3d0 (PIN_OUTPUT | MUX_MODE0) /* dcan1_tx */
+ 0x3d4 (MUX_MODE15)/* dcan1_rx.off */
+ 0x418 (PULL_DIS | MUX_MODE1) /* wakeup0.dcan1_rx */
+ >;
+ };
+
+ dcan1_pins_sleep: dcan1_pins_sleep {
+ pinctrl-single,pins = <
+ 0x3d0 (MUX_MODE15)/* dcan1_tx.off */
+ 0x3d4 (MUX_MODE15)/* dcan1_rx.off */
+ 0x418 (MUX_MODE15)/* wakeup0.off */
+ >;
+ };
};
&i2c1 {
@@ -142,3 +158,10 @@
&uart1 {
status = "okay";
};
+
+&dcan1 {
+ status = "ok";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&dcan1_pins_default>;
+ pinctrl-1 = <&dcan1_pins_sleep>;
+};
--
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 v3 1/8] net: can: c_can: Add timeout to c_can_hw_raminit_ti()
TI's RAMINIT DONE mechanism is buggy on AM43xx SoC and may not always
be set after the START bit is set. Although it seems to work fine even
in that case. So add a timeout mechanism to c_can_hw_raminit_wait_ti().
Don't bail out in that failure case but just print an error message.
Signed-off-by: Roger Quadros
---
drivers/net/can/c_can/c_can_platform.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index fb279d6..b144e71 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -75,10 +75,18 @@ static void c_can_plat_write_reg_aligned_to_32bit(const
struct c_can_priv *priv,
static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32 mask,
u32 val)
{
+ int timeout = 0;
/* We look only at the bits of our instance. */
val &= mask;
- while ((readl(priv->raminit_ctrlreg) & mask) != val)
+ while ((readl(priv->raminit_ctrlreg) & mask) != val) {
udelay(1);
+ timeout++;
+
+ if (timeout == 1000) {
+ dev_err(&priv->dev->dev, "%s: time out\n", __func__);
+ break;
+ }
+ }
}
static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
--
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 v3 8/8] net: can: c_can: Add support for TI am3352 DCAN
AM3352 SoC has 2 DCAN modules. Add compatible id and
raminit driver data for am3352 DCAN.
Signed-off-by: Roger Quadros
---
Documentation/devicetree/bindings/net/can/c_can.txt | 3 ++-
drivers/net/can/c_can/c_can_platform.c | 14 ++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 746cc07..27205d9 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -4,7 +4,8 @@ Bosch C_CAN/D_CAN controller Device Tree Bindings
Required properties:
- compatible : Should be "bosch,c_can" for C_CAN controllers and
"bosch,d_can" for D_CAN controllers.
- Can be "ti,dra7-d_can1" or "ti,dra7-d_can2".
+ Can be "ti,dra7-d_can1" or "ti,dra7-d_can2" or
+ "ti,am3352-d_can0" or "ti,am3352-d_can1".
- reg : physical base address and size of the C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index dc618ce..7dcdcde 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -209,6 +209,18 @@ static struct c_can_driver_data dra7_dcan2_drvdata = {
.raminit_pulse = true,
};
+static struct c_can_driver_data am3352_dcan0_drvdata = {
+ .id = BOSCH_D_CAN,
+ .raminit_start_bit = 0,
+ .raminit_done_bit = 8,
+};
+
+static struct c_can_driver_data am3352_dcan1_drvdata = {
+ .id = BOSCH_D_CAN,
+ .raminit_start_bit = 1,
+ .raminit_done_bit = 9,
+};
+
static struct platform_device_id c_can_id_table[] = {
{
.name = KBUILD_MODNAME,
@@ -231,6 +243,8 @@ static const struct of_device_id c_can_of_table[] = {
{ .compatible = "bosch,d_can", .data = &d_can_drvdata },
{ .compatible = "ti,dra7-d_can1", .data = &dra7_dcan1_drvdata },
{ .compatible = "ti,dra7-d_can2", .data = &dra7_dcan2_drvdata },
+ { .compatible = "ti,am3352-d_can0", .data = &am3352_dcan0_drvdata },
+ { .compatible = "ti,am3352-d_can1", .data = &am3352_dcan1_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
--
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 v3 3/8] net: can: c_can: Add RAMINIT register information to driver data
Some platforms (e.g. TI) need special RAMINIT register handling.
Provide a way to store RAMINIT register description in driver data.
Signed-off-by: Roger Quadros
---
drivers/net/can/c_can/c_can.h | 6 ++
drivers/net/can/c_can/c_can_platform.c | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 26c975d..c3b2108 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -171,6 +171,11 @@ enum c_can_dev_id {
struct c_can_driver_data {
enum c_can_dev_id id;
+
+ /* RAMINIT register description. Optional. */
+ u8 raminit_start_bit; /* START bit position in RAMINIT reg. */
+ u8 raminit_done_bit;/* DONE bit position in RAMINIT reg. */
+ bool raminit_pulse; /* If set, sets and clears START bit (pulse) */
};
/* c_can private data structure */
@@ -196,6 +201,7 @@ struct c_can_priv {
u32 comm_rcv_high;
u32 rxmasked;
u32 dlc[C_CAN_MSG_OBJ_TX_NUM];
+ const struct c_can_driver_data *drvdata;
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index 1546c2b..11946e8 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -250,6 +250,8 @@ static int c_can_plat_probe(struct platform_device *pdev)
}
priv = netdev_priv(dev);
+ priv->drvdata = drvdata;
+
switch (drvdata->id) {
case BOSCH_C_CAN:
priv->regs = reg_map_c_can;
--
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 v3 6/8] net: can: c_can: Disable pins when CAN interface is down
DRA7 CAN IP suffers from a problem which causes it to be prevented
from fully turning OFF (i.e. stuck in transition) if the module was
disabled while there was traffic on the CAN_RX line.
To work around this issue we select the SLEEP pin state by default
on probe and use the DEFAULT pin state on CAN up and back to the
SLEEP pin state on CAN down.
Signed-off-by: Roger Quadros
---
drivers/net/can/c_can/c_can.c | 20
drivers/net/can/c_can/c_can.h | 1 +
drivers/net/can/c_can/c_can_platform.c | 20
3 files changed, 41 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 8e78bb4..4dfc3ce 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -603,6 +604,15 @@ static int c_can_start(struct net_device *dev)
priv->can.state = CAN_STATE_ERROR_ACTIVE;
+ /* activate pins */
+ if (!IS_ERR(priv->pinctrl)) {
+ struct pinctrl_state *s;
+
+ s = pinctrl_lookup_state(priv->pinctrl, PINCTRL_STATE_DEFAULT);
+ if (!IS_ERR(s))
+ pinctrl_select_state(priv->pinctrl, s);
+ }
+
return 0;
}
@@ -611,6 +621,16 @@ static void c_can_stop(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_irq_control(priv, false);
+
+ /* deactivate pins */
+ if (!IS_ERR(priv->pinctrl)) {
+ struct pinctrl_state *s;
+
+ s = pinctrl_lookup_state(priv->pinctrl, PINCTRL_STATE_SLEEP);
+ if (!IS_ERR(s))
+ pinctrl_select_state(priv->pinctrl, s);
+ }
+
priv->can.state = CAN_STATE_STOPPED;
}
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index b5067bd..6b4ed1f 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -207,6 +207,7 @@ struct c_can_priv {
u32 rxmasked;
u32 dlc[C_CAN_MSG_OBJ_TX_NUM];
const struct c_can_driver_data *drvdata;
+ struct pinctrl *pinctrl;
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index ef1f5ce..d058820 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -230,6 +231,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
struct clk *clk;
const struct c_can_driver_data *drvdata;
struct device_node *np = pdev->dev.of_node;
+ struct pinctrl *pinctrl;
match = of_match_device(c_can_of_table, &pdev->dev);
if (match) {
@@ -241,6 +243,23 @@ static int c_can_plat_probe(struct platform_device *pdev)
return -ENODEV;
}
+ pinctrl = devm_pinctrl_get(&pdev->dev);
+ if (!IS_ERR(pinctrl)) {
+ struct pinctrl_state *s;
+
+ /* Deactivate pins to prevent DRA7 DCAN IP from being
+* stuck in transition when module is disabled.
+* Pins are activated in c_can_start() and deactivated
+* in c_can_stop()
+*/
+ s = pinctrl_lookup_state(pinctrl, PINCTRL_STATE_SLEEP);
+ if (!IS_ERR(s))
+ pinctrl_select_state(pinctrl, s);
+ } else {
+ dev_warn(&pdev->dev,
+"failed to get pinctrl\n");
+ }
+
/* get the appropriate clk */
clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(clk)) {
@@ -271,6 +290,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
priv = netdev_priv(dev);
priv->drvdata = drvdata;
+ priv->pinctrl = pinctrl;
switch (drvdata->id) {
case BOSCH_C_CAN:
--
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 v3 5/8] net: can: c_can: Add support for START pulse in RAMINIT sequence
Some SoCs e.g. (TI DRA7xx) need a START pulse to start the
RAMINIT sequence i.e. START bit must be set and cleared before
checking for the DONE bit status.
Signed-off-by: Roger Quadros
---
drivers/net/can/c_can/c_can_platform.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index d0ce439..ef1f5ce 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -124,6 +124,12 @@ static void c_can_hw_raminit_syscon(const struct
c_can_priv *priv, bool enable)
ctrl |= 1 << start_bit;
regmap_write(raminit->syscon, raminit->reg, ctrl);
+ /* clear START bit if start pulse is needed */
+ if (priv->drvdata->raminit_pulse) {
+ ctrl &= ~(1 << start_bit);
+ regmap_write(raminit->syscon, raminit->reg, ctrl);
+ }
+
ctrl |= 1 << done_bit;
c_can_hw_raminit_wait_syscon(priv, mask, ctrl);
}
--
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 v3 7/8] net: can: c_can: Add support for TI DRA7 DCAN
DRA7 SoC has 2 CAN IPs. Provide compatible IDs and RAMINIT
register data for both.
Signed-off-by: Roger Quadros
---
Documentation/devicetree/bindings/net/can/c_can.txt | 1 +
drivers/net/can/c_can/c_can_platform.c | 16
2 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 917ac0e..746cc07 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -4,6 +4,7 @@ Bosch C_CAN/D_CAN controller Device Tree Bindings
Required properties:
- compatible : Should be "bosch,c_can" for C_CAN controllers and
"bosch,d_can" for D_CAN controllers.
+ Can be "ti,dra7-d_can1" or "ti,dra7-d_can2".
- reg : physical base address and size of the C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index d058820..dc618ce 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -195,6 +195,20 @@ static struct c_can_driver_data d_can_drvdata = {
.id = BOSCH_D_CAN,
};
+static struct c_can_driver_data dra7_dcan1_drvdata = {
+ .id = BOSCH_D_CAN,
+ .raminit_start_bit = 3,
+ .raminit_done_bit = 1,
+ .raminit_pulse = true,
+};
+
+static struct c_can_driver_data dra7_dcan2_drvdata = {
+ .id = BOSCH_D_CAN,
+ .raminit_start_bit = 5,
+ .raminit_done_bit = 2,
+ .raminit_pulse = true,
+};
+
static struct platform_device_id c_can_id_table[] = {
{
.name = KBUILD_MODNAME,
@@ -215,6 +229,8 @@ MODULE_DEVICE_TABLE(platform, c_can_id_table);
static const struct of_device_id c_can_of_table[] = {
{ .compatible = "bosch,c_can", .data = &c_can_drvdata },
{ .compatible = "bosch,d_can", .data = &d_can_drvdata },
+ { .compatible = "ti,dra7-d_can1", .data = &dra7_dcan1_drvdata },
+ { .compatible = "ti,dra7-d_can2", .data = &dra7_dcan2_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
--
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 v3 4/8] net: can: c_can: Add syscon/regmap RAMINIT mechanism
Some TI SoCs like DRA7 have a RAMINIT register specification
different from the other AMxx SoCs and as expected by the
existing driver.
To add more insanity, this register is shared with other
IPs like DSS, PCIe and PWM.
Provides a more generic mechanism to specify the RAMINIT
register location and START/DONE bit position and use the
syscon/regmap framework to access the register.
Signed-off-by: Roger Quadros
---
.../devicetree/bindings/net/can/c_can.txt | 3 +
drivers/net/can/c_can/c_can.h | 9 ++-
drivers/net/can/c_can/c_can_platform.c | 93 +-
3 files changed, 65 insertions(+), 40 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 8f1ae81..917ac0e 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -12,6 +12,9 @@ Required properties:
Optional properties:
- ti,hwmods: Must be "d_can" or "c_can", n being the
instance number
+- syscon-raminit : Handle to system control region that contains the
+ RAMINIT register and register offset to the RAMINIT
+ register.
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index c3b2108..b5067bd 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -178,6 +178,12 @@ struct c_can_driver_data {
bool raminit_pulse; /* If set, sets and clears START bit (pulse) */
};
+/* Out of band RAMINIT register access via syscon regmap */
+struct c_can_raminit {
+ struct regmap *syscon; /* for raminit ctrl. reg. access */
+ unsigned int reg; /* register index within syscon */
+};
+
/* c_can private data structure */
struct c_can_priv {
struct can_priv can;/* must be the first member */
@@ -195,8 +201,7 @@ struct c_can_priv {
const u16 *regs;
void *priv; /* for board-specific data */
enum c_can_dev_id type;
- u32 __iomem *raminit_ctrlreg;
- int instance;
+ struct c_can_raminit raminit_sys; /* RAMINIT via syscon regmap */
void (*raminit) (const struct c_can_priv *priv, bool enable);
u32 comm_rcv_high;
u32 rxmasked;
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index 11946e8..d0ce439 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,14 +32,13 @@
#include
#include
#include
+#include
+#include
#include
#include "c_can.h"
-#define CAN_RAMINIT_START_MASK(i) (0x001 << (i))
-#define CAN_RAMINIT_DONE_MASK(i) (0x100 << (i))
-#define CAN_RAMINIT_ALL_MASK(i)(0x101 << (i))
#define DCAN_RAM_INIT_BIT (1 << 3)
static DEFINE_SPINLOCK(raminit_lock);
/*
@@ -72,47 +71,61 @@ static void c_can_plat_write_reg_aligned_to_32bit(const
struct c_can_priv *priv,
writew(val, priv->base + 2 * priv->regs[index]);
}
-static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32 mask,
- u32 val)
+static void c_can_hw_raminit_wait_syscon(const struct c_can_priv *priv,
+u32 mask, u32 val)
{
int timeout = 0;
+ const struct c_can_raminit *raminit = &priv->raminit_sys;
+ u32 ctrl;
+
/* We look only at the bits of our instance. */
val &= mask;
- while ((readl(priv->raminit_ctrlreg) & mask) != val) {
+ do {
udelay(1);
timeout++;
+ regmap_read(raminit->syscon, raminit->reg, &ctrl);
if (timeout == 1000) {
dev_err(&priv->dev->dev, "%s: time out\n", __func__);
break;
}
- }
+ } while ((ctrl & mask) != val);
}
-static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
+static void c_can_hw_raminit_syscon(const struct c_can_priv *priv, bool enable)
{
- u32 mask = CAN_RAMINIT_ALL_MASK(priv->instance);
+ u32 mask;
u32 ctrl;
+ const struct c_can_raminit *raminit = &priv->raminit_sys;
+ u8 start_bit, done_bit;
+
+ start_bit = priv->drvdata->raminit_start_bit;
+ done_bit = priv->drvdata->raminit_done_bit;
spin_lock(&raminit_lock);
- ctrl = readl(priv->raminit_ctrlreg);
+ mask = 1 << start_bit | 1 << done_bit;
+ regmap_read(raminit->syscon, raminit->reg, &ctrl);
+
/* We clear the done and start bit first. The start bit is
* looking at the 0 -> transition, but is not self clearing;
* And we clear the init done bit as well.
+* NOTE: DONE must b
[PATCH v3 0/8] net: can: Use syscon regmap for TI specific RAMINIT register
Hi, Some hardware (TI am43xx) has a buggy RAMINIT DONE mechanism and it might not always set the DONE bit. This will result in a lockup in c_can_hw_raminit_wait_ti(), so patch 1 adds a timeout mechanism there. There is a non compliancy within TI platforms with respect to the layout of the RAMINIT register. The patches 2 and 3 address this issue and make a flexible but standard way of defining the RAMINIT hardware register layout in the device tree. The RAMINIT register is accessed using the syscon regmap framework. Patches available at g...@github.com:rogerq/linux.git[for-v3.19/can] Patches are tested on am335x-evm, am437x-gp-evm and dra7-evm. Board support files to allow CAN testing on these boards are available at g...@github.com:rogerq/linux.git[for-v3.19/omap-dts-dcan] Changelog: v3: - allow driver data to be more than just CAN_ID - RAMINIT register data moved to driver data instead of device tree file. v2: - added "ti" vendor prefix to TI specific raminit properties. - split DTS changes into a separate series cheers, -roger --- Roger Quadros (8): net: can: c_can: Add timeout to c_can_hw_raminit_ti() net: can: c_can: Introduce c_can_driver_data structure net: can: c_can: Add RAMINIT register information to driver data net: can: c_can: Add syscon/regmap RAMINIT mechanism net: can: c_can: Add support for START pulse in RAMINIT sequence net: can: c_can: Disable pins when CAN interface is down net: can: c_can: Add support for TI DRA7 DCAN net: can: c_can: Add support for TI am3352 DCAN .../devicetree/bindings/net/can/c_can.txt | 5 + drivers/net/can/c_can/c_can.c | 20 ++ drivers/net/can/c_can/c_can.h | 20 +- drivers/net/can/c_can/c_can_platform.c | 207 +++-- 4 files changed, 191 insertions(+), 61 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 v3 2/8] net: can: c_can: Introduce c_can_driver_data structure
We want to have more data than just can_dev_id to be present
in the driver data e.g. TI platforms need RAMINIT register
description. Introduce the c_can_driver_data structure and move
the can_dev_id into it.
Tidy up the way it is used on probe().
Signed-off-by: Roger Quadros
---
drivers/net/can/c_can/c_can.h | 4 +++
drivers/net/can/c_can/c_can_platform.c | 52 +++---
2 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 99ad1aa..26c975d 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -169,6 +169,10 @@ enum c_can_dev_id {
BOSCH_D_CAN,
};
+struct c_can_driver_data {
+ enum c_can_dev_id id;
+};
+
/* c_can private data structure */
struct c_can_priv {
struct can_priv can;/* must be the first member */
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index b144e71..1546c2b 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -167,26 +167,34 @@ static void c_can_hw_raminit(const struct c_can_priv
*priv, bool enable)
}
}
+static struct c_can_driver_data c_can_drvdata = {
+ .id = BOSCH_C_CAN,
+};
+
+static struct c_can_driver_data d_can_drvdata = {
+ .id = BOSCH_D_CAN,
+};
+
static struct platform_device_id c_can_id_table[] = {
- [BOSCH_C_CAN_PLATFORM] = {
+ {
.name = KBUILD_MODNAME,
- .driver_data = BOSCH_C_CAN,
+ .driver_data = (kernel_ulong_t)&c_can_drvdata,
},
- [BOSCH_C_CAN] = {
+ {
.name = "c_can",
- .driver_data = BOSCH_C_CAN,
+ .driver_data = (kernel_ulong_t)&c_can_drvdata,
},
- [BOSCH_D_CAN] = {
+ {
.name = "d_can",
- .driver_data = BOSCH_D_CAN,
- }, {
- }
+ .driver_data = (kernel_ulong_t)&d_can_drvdata,
+ },
+ { /* sentinel */ },
};
MODULE_DEVICE_TABLE(platform, c_can_id_table);
static const struct of_device_id c_can_of_table[] = {
- { .compatible = "bosch,c_can", .data = &c_can_id_table[BOSCH_C_CAN] },
- { .compatible = "bosch,d_can", .data = &c_can_id_table[BOSCH_D_CAN] },
+ { .compatible = "bosch,c_can", .data = &c_can_drvdata },
+ { .compatible = "bosch,d_can", .data = &d_can_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
@@ -198,21 +206,19 @@ static int c_can_plat_probe(struct platform_device *pdev)
struct net_device *dev;
struct c_can_priv *priv;
const struct of_device_id *match;
- const struct platform_device_id *id;
struct resource *mem, *res;
int irq;
struct clk *clk;
-
- if (pdev->dev.of_node) {
- match = of_match_device(c_can_of_table, &pdev->dev);
- if (!match) {
- dev_err(&pdev->dev, "Failed to find matching dt id\n");
- ret = -EINVAL;
- goto exit;
- }
- id = match->data;
+ const struct c_can_driver_data *drvdata;
+
+ match = of_match_device(c_can_of_table, &pdev->dev);
+ if (match) {
+ drvdata = match->data;
+ } else if (pdev->id_entry->driver_data) {
+ drvdata = (struct c_can_driver_data *)
+ pdev->id_entry->driver_data;
} else {
- id = platform_get_device_id(pdev);
+ return -ENODEV;
}
/* get the appropriate clk */
@@ -244,7 +250,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
}
priv = netdev_priv(dev);
- switch (id->driver_data) {
+ switch (drvdata->id) {
case BOSCH_C_CAN:
priv->regs = reg_map_c_can;
switch (mem->flags & IORESOURCE_MEM_TYPE_MASK) {
@@ -303,7 +309,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
priv->device = &pdev->dev;
priv->can.clock.freq = clk_get_rate(clk);
priv->priv = clk;
- priv->type = id->driver_data;
+ priv->type = drvdata->id;
platform_set_drvdata(pdev, dev);
SET_NETDEV_DEV(dev, &pdev->dev);
--
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 2/5] ARM: OMAP2+: gpmc: Error out if timings fail in gpmc_probe_generic_child()
On 11/04/2014 03:14 AM, Tony Lindgren wrote: > * Tony Lindgren [141103 16:48]: >> --- a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi >> +++ b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi >> +gpmc,device-width = <1>; >> +gpmc,burst-length = <4>; > > I've left out the gpmc,burst-length as that produces now > warnings about not being used and does not seem to work if > enabled. OK. Seems like it must be used together with either 'gpmc,burst-read' or/and 'gpmc,burst-write' cheers, -roger > >> --- a/arch/arm/boot/dts/omap3-sb-t35.dtsi >> +++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi >> +gpmc,device-width = <1>; >> +gpmc,burst-length = <4>; > > And here too. > > Regards, > > Tony > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
