Hi Suman,
Anna, Suman wrote on Monday, June 20, 2016 9:49 PM:
> It does happen when the pruss module is exercised. We found this when we
> tried to do a standby test on suspend, and while it worked on AM33xx,
> AM437x failed because of this difference.
Okay, seems on am335x, PER doesn't have
Hi Suman,
Anna, Suman wrote on Monday, June 20, 2016 9:49 PM:
> It does happen when the pruss module is exercised. We found this when we
> tried to do a standby test on suspend, and while it worked on AM33xx,
> AM437x failed because of this difference.
Okay, seems on am335x, PER doesn't have
Hi,
J, KEERTHY wrote on Monday, June 20, 2016 9:22 AM:
> pruss hwmod RSTST register wrongly points to PWRSTCTRL register in case of
> am43xx. Fix the RSTST register offset value.
> This can lead to setting of wrong power state values for PER domain.
Just curious, does it happen or noticed by
Hi,
J, KEERTHY wrote on Monday, June 20, 2016 9:22 AM:
> pruss hwmod RSTST register wrongly points to PWRSTCTRL register in case of
> am43xx. Fix the RSTST register offset value.
> This can lead to setting of wrong power state values for PER domain.
Just curious, does it happen or noticed by
Hi George,
On Tue, Jul 09, 2013 at 14:47:26, Cherian, George wrote:
> + usb_otg_hs1: am4372_dwc3@4838 {
Wouldn't "usb" a better node name ?
> + compatible = "ti,am437x-dwc3";
Usage of wild card is discouraged per DT documentation.
Regards
Afzal
--
To
Hi George,
On Tue, Jul 09, 2013 at 14:47:26, Cherian, George wrote:
+ usb_otg_hs1: am4372_dwc3@4838 {
Wouldn't usb a better node name ?
+ compatible = ti,am437x-dwc3;
Usage of wild card is discouraged per DT documentation.
Regards
Afzal
--
To
Hi Tony,
On Thu, Jun 13, 2013 at 15:24:54, Tony Lindgren wrote:
> * Mohammed, Afzal [130613 00:04]:
> > Patch 10 "ARM: OMAP2+: AM43x: basic dt support" is missing in
> > omap-for-v3.11/soc branch and omap soc pull request, can you
> > please help patch 10 also to
Hi Tony,
On Wed, Jun 12, 2013 at 22:42:00, Tony Lindgren wrote:
> I've updated this patch to remove the "default y" and
> "depends on ARCH_OMAP2PLUS" entries for the usual reasons
> and applied the first ten patches into omap-for-v3.11/soc.
Thanks.
Patch 10 "ARM: OMAP2+: AM43x: basic dt
Hi Tony,
On Wed, Jun 12, 2013 at 22:42:00, Tony Lindgren wrote:
I've updated this patch to remove the default y and
depends on ARCH_OMAP2PLUS entries for the usual reasons
and applied the first ten patches into omap-for-v3.11/soc.
Thanks.
Patch 10 ARM: OMAP2+: AM43x: basic dt support is
Hi Tony,
On Thu, Jun 13, 2013 at 15:24:54, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [130613 00:04]:
Patch 10 ARM: OMAP2+: AM43x: basic dt support is missing in
omap-for-v3.11/soc branch and omap soc pull request, can you
please help patch 10 also to go upstream.
Hmm
Hi Tony,
On Mon, May 27, 2013 at 20:03:27, Mohammed, Afzal wrote:
> This series adds initial support for AM43x based SoC's. To boot
> AM43x, in addition to these patches, PRCM support is also needed,
> which would be posted later as a separate series. DT sources doesn't
> have &quo
Hi Tony,
On Mon, May 27, 2013 at 20:03:27, Mohammed, Afzal wrote:
This series adds initial support for AM43x based SoC's. To boot
AM43x, in addition to these patches, PRCM support is also needed,
which would be posted later as a separate series. DT sources doesn't
have ti,hwmod entry
Hi Benoit,
On Wed, May 29, 2013 at 19:05:35, Cousson, Benoit wrote:
> And in this case, you do not introduce any new revision.
>
> There is no point to update the binding each time we add a new SoC
> variant that will contain the exact same IP.
>
> I think it will mainly confuse the user that
Hi Benoit,
On Wed, May 29, 2013 at 19:05:35, Cousson, Benoit wrote:
And in this case, you do not introduce any new revision.
There is no point to update the binding each time we add a new SoC
variant that will contain the exact same IP.
I think it will mainly confuse the user that will
Hi Benoit,
On Wed, May 29, 2013 at 14:09:18, Cousson, Benoit wrote:
> On 05/29/2013 10:06 AM, Mohammed, Afzal wrote:
> > On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
> >> On 05/28/2013 03:25 PM, Jon Hunter wrote:
> >>> If you are adding more compatibil
Hi Jon,
On Wed, May 29, 2013 at 02:56:05, Jon Hunter wrote:
> Changelog should state why this is needed.
Please see my reply on 11/14 thread.
Regards
Afzal
Hi Jon,
On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
> On 05/28/2013 03:25 PM, Jon Hunter wrote:
> >>ti,am335x-timer (applicable to AM335x devices)
> >>ti,am335x-timer-1ms (applicable to AM335x devices)
> >> +
Hi Jon,
On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
On 05/28/2013 03:25 PM, Jon Hunter wrote:
ti,am335x-timer (applicable to AM335x devices)
ti,am335x-timer-1ms (applicable to AM335x devices)
+ ti,am4372-timer-1ms,
Hi Jon,
On Wed, May 29, 2013 at 02:56:05, Jon Hunter wrote:
Changelog should state why this is needed.
Please see my reply on 11/14 thread.
Regards
Afzal
Hi Benoit,
On Wed, May 29, 2013 at 14:09:18, Cousson, Benoit wrote:
On 05/29/2013 10:06 AM, Mohammed, Afzal wrote:
On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
On 05/28/2013 03:25 PM, Jon Hunter wrote:
If you are adding more compatibility strings, then this implies
Hi Santosh,
On Tue, Feb 19, 2013 at 15:39:32, Shilimkar, Santosh wrote:
> After looking at the specs, you don't need the SMP mode since ACP
> isn't being used.
> TWD use for AM437x is also limited because these times stops in
> low power sates and there you will need broad-cast mechanism which
Hi Santosh,
On Tue, Feb 19, 2013 at 16:30:13, Shilimkar, Santosh wrote:
> On Tuesday 19 February 2013 04:22 PM, Mohammed, Afzal wrote:
> > SoC support is already added in patch 7/8. This is board (which doesn't
> > exist now) support, hence a pre-silicon temporary one to valid
Hi Santosh,
On Tue, Feb 19, 2013 at 16:05:22, Shilimkar, Santosh wrote:
> On Monday 18 February 2013 05:08 PM, Afzal Mohammed wrote:
> > AM43 SoC is in pre-silicon stage, meanwhile it has been modelled in
> > a pre-silicon platform. To validate and boot Linux in pre-silicon
> > platform that
Hi Santosh,
On Tue, Feb 19, 2013 at 15:55:59, Shilimkar, Santosh wrote:
> With DT, IIRC DEBUGLL is broken. So did you hack debug-macro.S
> to get the earlyprintk working ?
No, on linux-next, ll debug works properly.
Regards
Afzal
Hi Felipe,
On Mon, Feb 18, 2013 at 23:52:40, Balbi, Felipe wrote:
> On Mon, Feb 18, 2013 at 05:08:16PM +0530, Afzal Mohammed wrote:
> > + uart1: serial@44e09000 {
> > + compatible = "ti,am4372-uart","ti,omap2-uart";
> > + clock-frequency =
Hi Rob,
On Mon, Feb 18, 2013 at 19:17:29, Rob Herring wrote:
> On 02/18/2013 12:30 AM, Afzal Mohammed wrote:
> > Register percpu local timer for scheduler tick in the case of one core
> > SMP configuration. In other cases - secondary cpu's as well as boot
> > cpu's having more than one core,
Hi Rob,
On Mon, Feb 18, 2013 at 19:17:29, Rob Herring wrote:
On 02/18/2013 12:30 AM, Afzal Mohammed wrote:
Register percpu local timer for scheduler tick in the case of one core
SMP configuration. In other cases - secondary cpu's as well as boot
cpu's having more than one core, this is
Hi Felipe,
On Mon, Feb 18, 2013 at 23:52:40, Balbi, Felipe wrote:
On Mon, Feb 18, 2013 at 05:08:16PM +0530, Afzal Mohammed wrote:
+ uart1: serial@44e09000 {
+ compatible = ti,am4372-uart,ti,omap2-uart;
+ clock-frequency = 4800;
+
Hi Santosh,
On Tue, Feb 19, 2013 at 15:55:59, Shilimkar, Santosh wrote:
With DT, IIRC DEBUGLL is broken. So did you hack debug-macro.S
to get the earlyprintk working ?
No, on linux-next, ll debug works properly.
Regards
Afzal
Hi Santosh,
On Tue, Feb 19, 2013 at 16:05:22, Shilimkar, Santosh wrote:
On Monday 18 February 2013 05:08 PM, Afzal Mohammed wrote:
AM43 SoC is in pre-silicon stage, meanwhile it has been modelled in
a pre-silicon platform. To validate and boot Linux in pre-silicon
platform that emulates
Hi Santosh,
On Tue, Feb 19, 2013 at 16:30:13, Shilimkar, Santosh wrote:
On Tuesday 19 February 2013 04:22 PM, Mohammed, Afzal wrote:
SoC support is already added in patch 7/8. This is board (which doesn't
exist now) support, hence a pre-silicon temporary one to validate it.
I mean we can
Hi Santosh,
On Tue, Feb 19, 2013 at 15:39:32, Shilimkar, Santosh wrote:
After looking at the specs, you don't need the SMP mode since ACP
isn't being used.
TWD use for AM437x is also limited because these times stops in
low power sates and there you will need broad-cast mechanism which
Hi Tomi, Florian,
On Tue, Jan 15, 2013 at 19:00:50, Mohammed, Afzal wrote:
> This series makes da8xx-fb driver (device found on DaVinci and AM335x)
> capable of handling runtime timing configuration by adding fb_set_par.
>
> The last change adds actual fb_set_par support. Othe
Hi Tomi, Florian,
On Tue, Jan 15, 2013 at 19:00:50, Mohammed, Afzal wrote:
This series makes da8xx-fb driver (device found on DaVinci and AM335x)
capable of handling runtime timing configuration by adding fb_set_par.
The last change adds actual fb_set_par support. Other preceeding
changes
Hi Roger,
On Fri, Feb 01, 2013 at 20:01:38, Quadros, Roger wrote:
> but DT boot is not supported for OMAP USB Host. How did you get it to work?
>
> Are you testing the Host connector or the OTG connector?
If you see latest changes on musb_dsps.c, you will be able to find
out.
As beagle bone
Hi Roger,
On Fri, Feb 01, 2013 at 19:55:14, Quadros, Roger wrote:
> Thanks Afzal :). You mean the non device tree boot right?
No, dt boot, am335x can only dt boot.
Regards
Afzal
Hi Felipe, Roger,
On Wed, Jan 30, 2013 at 18:49:17, Mohammed, Afzal wrote:
> On Wed, Jan 30, 2013 at 18:45:04, Balbi, Felipe wrote:
> > On Wed, Jan 30, 2013 at 02:48:50PM +0200, Roger Quadros wrote:
> > > I would appreciate if someone who knows more about b
Hi Felipe, Roger,
On Wed, Jan 30, 2013 at 18:49:17, Mohammed, Afzal wrote:
On Wed, Jan 30, 2013 at 18:45:04, Balbi, Felipe wrote:
On Wed, Jan 30, 2013 at 02:48:50PM +0200, Roger Quadros wrote:
I would appreciate if someone who knows more about beaglebone can help
with verification
Hi Roger,
On Fri, Feb 01, 2013 at 19:55:14, Quadros, Roger wrote:
Thanks Afzal :). You mean the non device tree boot right?
No, dt boot, am335x can only dt boot.
Regards
Afzal
Hi Roger,
On Fri, Feb 01, 2013 at 20:01:38, Quadros, Roger wrote:
but DT boot is not supported for OMAP USB Host. How did you get it to work?
Are you testing the Host connector or the OTG connector?
If you see latest changes on musb_dsps.c, you will be able to find
out.
As beagle bone
Hi Felipe,
On Wed, Jan 30, 2013 at 18:45:04, Balbi, Felipe wrote:
> On Wed, Jan 30, 2013 at 02:48:50PM +0200, Roger Quadros wrote:
> > I would appreciate if someone who knows more about beaglebone can help
> > with verification.
> >
> > I could find that Robert C Nelson (now in cc) is
Hi Roger,
On Wed, Jan 30, 2013 at 18:18:50, Quadros, Roger wrote:
> On 01/30/2013 02:08 PM, Mohammed, Afzal wrote:
> > Please try to ensure that beagle bone USB0 works with this.
> I do not have beaglebone with me and don't seem to find beaglebone
> board support in mainline.
Hi Roger,
On Mon, Jan 28, 2013 at 17:00:01, Quadros, Roger wrote:
> NOTE: Tested on 4460ES-B1 Panda and BeagleBoard C4 only. Other boards are only
> build tested.
Please try to ensure that beagle bone USB0 works with this.
Regards
Afzal
Hi Roger,
On Mon, Jan 28, 2013 at 17:00:01, Quadros, Roger wrote:
NOTE: Tested on 4460ES-B1 Panda and BeagleBoard C4 only. Other boards are only
build tested.
Please try to ensure that beagle bone USB0 works with this.
Regards
Afzal
Hi Roger,
On Wed, Jan 30, 2013 at 18:18:50, Quadros, Roger wrote:
On 01/30/2013 02:08 PM, Mohammed, Afzal wrote:
Please try to ensure that beagle bone USB0 works with this.
I do not have beaglebone with me and don't seem to find beaglebone
board support in mainline.
Ok. Fyi, beagle bone
Hi Felipe,
On Wed, Jan 30, 2013 at 18:45:04, Balbi, Felipe wrote:
On Wed, Jan 30, 2013 at 02:48:50PM +0200, Roger Quadros wrote:
I would appreciate if someone who knows more about beaglebone can help
with verification.
I could find that Robert C Nelson (now in cc) is maintaining out of
Hi Paul,
On Fri, Jan 25, 2013 at 17:48:22, Mohammed, Afzal wrote:
> On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
> > like MPU CPUFreq. I'd suggest reverting
> > 241d3a8dca239610d3d991bf58d4fe38c2d86fd5 or using a similar approach.
> As you prefer reverting t
Hi Paul,
On Fri, Jan 25, 2013 at 17:48:22, Mohammed, Afzal wrote:
On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
like MPU CPUFreq. I'd suggest reverting
241d3a8dca239610d3d991bf58d4fe38c2d86fd5 or using a similar approach.
As you prefer reverting the above commit, I will proceed
Hi Mike,
On Sat, Jan 26, 2013 at 03:50:32, Mike Turquette wrote:
> Is MULT_ROUND_UP doing the right thing for you in the clk_divider code?
> What is the clock rate requested of the parent PLL? I just want to make
> sure that we're doing the right thing in the basic divider code.
Actually
Hi Mike,
On Sat, Jan 26, 2013 at 04:05:24, Mike Turquette wrote:
> Thank you for the information. In short, the way you program your clock
> depend on the configuration of your lcdc device.
>
> As such I am not sure the basic divider is the right choice for you.
> You might be better off
Hi Mike,
On Sat, Jan 26, 2013 at 04:14:53, Mike Turquette wrote:
> I think Paul W. or someone on the TI side should weigh in on your clkdev
> entries. My main point is that the actual tree should be modeled and
> clocks shouldn't be globbed together unnecessarily. As mentioned in the
> other
Hi Mike,
On Sat, Jan 26, 2013 at 04:14:53, Mike Turquette wrote:
I think Paul W. or someone on the TI side should weigh in on your clkdev
entries. My main point is that the actual tree should be modeled and
clocks shouldn't be globbed together unnecessarily. As mentioned in the
other mail
Hi Mike,
On Sat, Jan 26, 2013 at 04:05:24, Mike Turquette wrote:
Thank you for the information. In short, the way you program your clock
depend on the configuration of your lcdc device.
As such I am not sure the basic divider is the right choice for you.
You might be better off creating a
Hi Mike,
On Sat, Jan 26, 2013 at 03:50:32, Mike Turquette wrote:
Is MULT_ROUND_UP doing the right thing for you in the clk_divider code?
What is the clock rate requested of the parent PLL? I just want to make
sure that we're doing the right thing in the basic divider code.
Actually
Hi Kishon,
On Thu, Jan 24, 2013 at 17:21:45, Mohammed, Afzal wrote:
> On Wed, Jan 23, 2013 at 19:56:37, ABRAHAM, KISHON VIJAY wrote:
> > On Wednesday 23 January 2013 07:28 PM, Mohammed, Afzal wrote:
> > > USB first instance of am335x works in mainline as of now.
&g
Hi Paul,
On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
> On Wed, 23 Jan 2013, Afzal Mohammed wrote:
> > Currently round rate function would return proper rate iff requested
> > rate exactly matches the PLL lockable rate. This causes set_rate to
> > fail if exact rate could not be set.
Hi Mike,
On Thu, Jan 24, 2013 at 22:36:30, Mike Turquette wrote:
> Quoting Mohammed, Afzal (2013-01-24 03:29:15)
> > It is a functional constraint: divider has 8 bits and it can have
> > all possible values (0 to 255) and divider value corresponds to
> > value set in the
Hi Mike,
On Thu, Jan 24, 2013 at 22:30:44, Mike Turquette wrote:
> Quoting Mohammed, Afzal (2013-01-24 03:36:02)
> > So there are 3 - LIDD is actually not for present use case, CORE could
> > be clubbed with the divider to have a composite clock. And CORE is
> > in
Hi Mike,
On Thu, Jan 24, 2013 at 22:30:44, Mike Turquette wrote:
Quoting Mohammed, Afzal (2013-01-24 03:36:02)
So there are 3 - LIDD is actually not for present use case, CORE could
be clubbed with the divider to have a composite clock. And CORE is
in functional clock path and logically
Hi Mike,
On Thu, Jan 24, 2013 at 22:36:30, Mike Turquette wrote:
Quoting Mohammed, Afzal (2013-01-24 03:29:15)
It is a functional constraint: divider has 8 bits and it can have
all possible values (0 to 255) and divider value corresponds to
value set in the 8 bits. But depending
Hi Paul,
On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
On Wed, 23 Jan 2013, Afzal Mohammed wrote:
Currently round rate function would return proper rate iff requested
rate exactly matches the PLL lockable rate. This causes set_rate to
fail if exact rate could not be set. Instead
Hi Kishon,
On Thu, Jan 24, 2013 at 17:21:45, Mohammed, Afzal wrote:
On Wed, Jan 23, 2013 at 19:56:37, ABRAHAM, KISHON VIJAY wrote:
On Wednesday 23 January 2013 07:28 PM, Mohammed, Afzal wrote:
USB first instance of am335x works in mainline as of now.
Can you check if this series indeed
Hi Kishon,
On Wed, Jan 23, 2013 at 19:56:37, ABRAHAM, KISHON VIJAY wrote:
> On Wednesday 23 January 2013 07:28 PM, Mohammed, Afzal wrote:
> > USB first instance of am335x works in mainline as of now.
> Can you check if this series indeed breaks am335x?
>
> Thanks for your
Hi Mike,
On Thu, Jan 24, 2013 at 01:52:04, Mike Turquette wrote:
> Quoting Afzal Mohammed (2013-01-23 03:48:56)
> > +static inline void da8xx_fb_clkc_enable(void)
> > +{
> > if (lcd_revision == LCD_VERSION_2)
> > lcdc_write(LCD_V2_DMA_CLK_EN | LCD_V2_LIDD_CLK_EN |
> >
Hi Mike,
On Thu, Jan 24, 2013 at 03:10:53, Mike Turquette wrote:
> Quoting Afzal Mohammed (2013-01-23 03:38:52)
> > Some of clocks can have a limit on minimum divider value that can be
> > programmed, prepare for such a support.
> > Add a new field min_div for the basic divider clock and a new
Hi Mike,
On Thu, Jan 24, 2013 at 03:10:53, Mike Turquette wrote:
Quoting Afzal Mohammed (2013-01-23 03:38:52)
Some of clocks can have a limit on minimum divider value that can be
programmed, prepare for such a support.
Add a new field min_div for the basic divider clock and a new dynamic
Hi Mike,
On Thu, Jan 24, 2013 at 01:52:04, Mike Turquette wrote:
Quoting Afzal Mohammed (2013-01-23 03:48:56)
+static inline void da8xx_fb_clkc_enable(void)
+{
if (lcd_revision == LCD_VERSION_2)
lcdc_write(LCD_V2_DMA_CLK_EN | LCD_V2_LIDD_CLK_EN |
Hi Kishon,
On Wed, Jan 23, 2013 at 19:56:37, ABRAHAM, KISHON VIJAY wrote:
On Wednesday 23 January 2013 07:28 PM, Mohammed, Afzal wrote:
USB first instance of am335x works in mainline as of now.
Can you check if this series indeed breaks am335x?
Thanks for your help.
Do you have a tree
Hi Koen,
On Tue, Jan 22, 2013 at 22:32:56, Koen Kooi wrote:
> Actually it uses nop-phy as a phy, which is missing from
> arch/arm/boot/dts/am33xx.dtsi, so mainline is already broken. But adding the
> nop-phy to the DT is easy enough to patch in locally.
USB first instance of am335x works in
Hi Mike,
On Wed, Jan 16, 2013 at 10:32:10, Nori, Sekhar wrote:
> On 1/15/2013 9:02 PM, Mike Turquette wrote:
> > Quoting Afzal Mohammed (2013-01-15 05:44:36)
> >> Note:
> >> A better (if allowable) solution may be to represent clock divider in
> >> LCDC IP as a basic divider clock - the one
Hi,
On Wed, Jan 23, 2013 at 00:15:09, Rob Clark wrote:
> > Wouldn't it be better to delete da8xx-fb.* and switch to Rob Clarks DRM
> > based driver for this IP block?
> we probably can't delete da8xx-fb, but I think it would be ok to only
> use it for legacy platforms not yet ported to DT.
We
Hi,
On Wed, Jan 23, 2013 at 00:15:09, Rob Clark wrote:
Wouldn't it be better to delete da8xx-fb.* and switch to Rob Clarks DRM
based driver for this IP block?
we probably can't delete da8xx-fb, but I think it would be ok to only
use it for legacy platforms not yet ported to DT.
We can't
Hi Mike,
On Wed, Jan 16, 2013 at 10:32:10, Nori, Sekhar wrote:
On 1/15/2013 9:02 PM, Mike Turquette wrote:
Quoting Afzal Mohammed (2013-01-15 05:44:36)
Note:
A better (if allowable) solution may be to represent clock divider in
LCDC IP as a basic divider clock - the one defined in
Hi Koen,
On Tue, Jan 22, 2013 at 22:32:56, Koen Kooi wrote:
Actually it uses nop-phy as a phy, which is missing from
arch/arm/boot/dts/am33xx.dtsi, so mainline is already broken. But adding the
nop-phy to the DT is easy enough to patch in locally.
USB first instance of am335x works in
Hi Steffen,
On Mon, Jan 07, 2013 at 14:51:15, Mohammed, Afzal wrote:
> On Mon, Jan 07, 2013 at 14:41:31, Steffen Trumtrar wrote:
> > On Mon, Jan 07, 2013 at 10:41:30AM +0530, Afzal Mohammed wrote:
> > > +- display-timings: list of different videomodes supported by the
Hi Steffen,
On Mon, Jan 07, 2013 at 14:51:15, Mohammed, Afzal wrote:
On Mon, Jan 07, 2013 at 14:41:31, Steffen Trumtrar wrote:
On Mon, Jan 07, 2013 at 10:41:30AM +0530, Afzal Mohammed wrote:
+- display-timings: list of different videomodes supported by the lcd
+ panel, represented
Hi,
On Wed, Dec 12, 2012 at 13:30:56, Hiremath, Vaibhav wrote:
> On Wed, Dec 12, 2012 at 12:50:28, Manjunathappa, Prakash wrote:
> > Agreed, should not result in build error. But is it ok to show this option
> > on the platforms which do not have this IP?
> >
>
> You can choose to put machine
Hi Steffen,
On Mon, Jan 07, 2013 at 14:41:31, Steffen Trumtrar wrote:
> On Mon, Jan 07, 2013 at 10:41:30AM +0530, Afzal Mohammed wrote:
> > Obtain fb_videomode details for the connected lcd panel using the
> > display timing details present in DT.
> > +- display-timings: list of different
Hi Steffen,
On Mon, Jan 07, 2013 at 14:41:31, Steffen Trumtrar wrote:
On Mon, Jan 07, 2013 at 10:41:30AM +0530, Afzal Mohammed wrote:
Obtain fb_videomode details for the connected lcd panel using the
display timing details present in DT.
+- display-timings: list of different videomodes
Hi,
On Wed, Dec 12, 2012 at 13:30:56, Hiremath, Vaibhav wrote:
On Wed, Dec 12, 2012 at 12:50:28, Manjunathappa, Prakash wrote:
Agreed, should not result in build error. But is it ok to show this option
on the platforms which do not have this IP?
You can choose to put machine
+ linux-omap and Daniel
On Fri, Oct 19, 2012 at 16:20:21, Mohammed, Afzal wrote:
> add am33xx rtc node.
>
> Signed-off-by: Afzal Mohammed
> ---
>
> Based on v3.7-rc1,
> Dependent on series "rtc: omap dt support (for am33xx)",
> (https://lkml.org/lkml/2012/
+ linux-omap and Daniel
On Fri, Oct 19, 2012 at 16:20:21, Mohammed, Afzal wrote:
add am33xx rtc node.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Based on v3.7-rc1,
Dependent on series rtc: omap dt support (for am33xx),
(https://lkml.org/lkml/2012/10/19/163)
Tested on Beagle Bone
Hi Mark,
On Mon, Sep 24, 2012 at 16:21:40, Mark Jackson wrote:
> On 24/09/12 05:51, Mohammed, Afzal wrote:
> > It seems you are using PSP Kernel.
> >
> > Invoking omap_init_gpmc before gpmc request should help.
>
> Okay ... I'm now using earlyprintk and omap_init_g
Hi Mark,
On Mon, Sep 24, 2012 at 16:21:40, Mark Jackson wrote:
On 24/09/12 05:51, Mohammed, Afzal wrote:
It seems you are using PSP Kernel.
Invoking omap_init_gpmc before gpmc request should help.
Okay ... I'm now using earlyprintk and omap_init_gpmc(), but I still get boot
hangs
Hi Mark,
On Sat, Sep 22, 2012 at 00:57:38, Mark Jackson wrote:
> I'm developing a beaglebone cape board which requires the use of a GPMC
> chip select.
>
> I've chosen GPMC_CS0, and in board-am335xevm.c, I have added the following:-
>
> static void gpmc_test()
> {
> unsigned long base =
Hi Mark,
On Sat, Sep 22, 2012 at 00:57:38, Mark Jackson wrote:
I'm developing a beaglebone cape board which requires the use of a GPMC
chip select.
I've chosen GPMC_CS0, and in board-am335xevm.c, I have added the following:-
static void gpmc_test()
{
unsigned long base =
Hi Alessandro,
On Sat, Aug 11, 2012 at 01:27:11, Nori, Sekhar wrote:
> On 7/27/2012 5:53 PM, Afzal Mohammed wrote:
> > This series makes rtc-omap driver DT capable, adds AM33xx
> > RTC DT support along with a few enchancments to the driver.
> >
> > rtc-omap driver is made intelligent enough to
Hi Alessandro,
On Sat, Aug 11, 2012 at 01:27:11, Nori, Sekhar wrote:
On 7/27/2012 5:53 PM, Afzal Mohammed wrote:
This series makes rtc-omap driver DT capable, adds AM33xx
RTC DT support along with a few enchancments to the driver.
rtc-omap driver is made intelligent enough to handle
Hi Sergei,
On Wed, Jul 25, 2012 at 22:29:24, Sergei Shtylyov wrote:
> >>> + rtc@44e3e000 {
>
> >> Address postfix in the node name without "reg" property?
>
> > As per [1], "The unit-address is included if the node describes
> > a device with an address".
>
>Which in this case
Hi Sergei,
On Wed, Jul 25, 2012 at 22:29:24, Sergei Shtylyov wrote:
+ rtc@44e3e000 {
Address postfix in the node name without reg property?
As per [1], The unit-address is included if the node describes
a device with an address.
Which in this case it doesn't.
Hi Sergei,
On Wed, Jul 25, 2012 at 16:50:56, Sergei Shtylyov wrote:
> > + rtc@44e3e000 {
>
> Address postfix in the node name without "reg" property?
As per [1], "The unit-address is included if the node describes
a device with an address".
Here even though reg property is not
Hi Sergei,
On Wed, Jul 25, 2012 at 16:45:29, Sergei Shtylyov wrote:
> > +/* OMAP_RTC_KICKER values */
> > +#defineKICK0_VALUE (0x83e70b13)
> > +#defineKICK1_VALUE (0x95a4f1e0)
>
> Parens not needed around simple literals.
Thanks for catching
Hi Sergei,
On Wed, Jul 25, 2012 at 16:45:29, Sergei Shtylyov wrote:
+/* OMAP_RTC_KICKER values */
+#defineKICK0_VALUE (0x83e70b13)
+#defineKICK1_VALUE (0x95a4f1e0)
Parens not needed around simple literals.
Thanks for catching it
Hi Sergei,
On Wed, Jul 25, 2012 at 16:50:56, Sergei Shtylyov wrote:
+ rtc@44e3e000 {
Address postfix in the node name without reg property?
As per [1], The unit-address is included if the node describes
a device with an address.
Here even though reg property is not present,
Hi Sergei,
On Tue, Jul 24, 2012 at 16:41:16, Sergei Shtylyov wrote:
> > static struct platform_device da8xx_rtc_device = {
> > - .name = "omap_rtc",
> > + .name = "am1808-rtc",
>
> Why not "da8xx-rtc". Kick registers exist startting with
> DA830/OMAP-L137/AM1707,
Hi Sergei,
On Tue, Jul 24, 2012 at 16:41:16, Sergei Shtylyov wrote:
static struct platform_device da8xx_rtc_device = {
- .name = omap_rtc,
+ .name = am1808-rtc,
Why not da8xx-rtc. Kick registers exist startting with
DA830/OMAP-L137/AM1707, not only on
96 matches
Mail list logo
