Re: [PATCH] staging: tidspbridge: enable watchdog by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 14, 2012 at 3:06 AM, Ramirez Luna, Omar <omar.ramirez@xxxxxx> wrote:
> On Feb 11, 2012 3:03 PM, "Felipe Contreras" <felipe.contreras@xxxxxxxxx> wrote:
>>
>> On Sat, Feb 11, 2012 at 9:19 PM, Ramirez Luna, Omar <omar.ramirez@xxxxxx> wrote:
>> >
>> > On Feb 10, 2012 12:44 PM, "Felipe Contreras" <felipe.contreras@xxxxxxxxx>
>> > wrote:
>> >>
>> >> On Fri, Feb 10, 2012 at 10:35 PM, Dan Carpenter
>> >> <dan.carpenter@xxxxxxxxxx> wrote:
>> >> > On Fri, Feb 10, 2012 at 09:42:32PM +0200, Felipe Contreras wrote:
>> >> >> On Fri, Feb 10, 2012 at 8:00 PM, Dan Carpenter
>> >> >> <dan.carpenter@xxxxxxxxxx> wrote:
>> >> >> > On Fri, Feb 10, 2012 at 01:30:48AM +0200, Felipe Contreras wrote:
>> >> >> >> It's not an oops, it's a warning, and again, it depends on the
>> >> >> >> firmware being used. We don't have control over that, and we have no
>> >> >> >> way to detect if this feature is there. It's up to the user.
>> >> >> >
>> >> >> > Perhaps just remove the warning message and handle the condition
>> >> >> > instead of printing a stack dump?  The user should be triggering
>> >> >> > stack dumps.  What on earth?
>> >> >>
>> >> >> The warning doesn't come from the driver.
>> >> >
>> >> > I'm not sure I understand.  Are you saying that because it comes
>> >> > from the arch/ directory, it can't be fixed?  I have good news for
>> >> > you my friend.  :)  It's all open source!  \o/
>> >>
>> >> The fact that you _can_ remove the warning doesn't mean you should. To
>> >> me it sounds like a proper warning.
>> >>
>> >> > Anyway, I saw in another email that Omar is working on a fix so
>> >> > probably we can just wait for his patch, yes?
>> >>
>> >> He only proposed a solution, I doubt he is working on. And to me, that
>> >> sounded like a hack rather than a proper fix.
>> >
>> > I'm out on travel but will be able to look at it on Monday.
>> >
>> > Well,  I think it is the right way, you look on the firmware if it has WDT
>> > you use it if it doesn't then you don't. Rather than guessing if you have
>> > the feature. It would be like reading a config option in the firmware.
>>
>> Yeah, but it's not really firmware, it's an operating system image. I
>> can be running Linux there, and I might have implemented WDT. How is
>> that code going to find that out?
>
> Tidspbridge loader doesn't support that use case, baseimage and let's
> say a dsp-linuximg won't have the same layout, hence it won't be able
> to parse and load the latter.
>
> When that case is applicable, we should first modify the loader code
> or prepare the baseimages to be common so we can get rid of specific
> loaders and just dump them into memory.

I'd say the less workarounds, the better.

> WDT could be detected by prepending common symbols into the baseimages
> or just making the new images to treat all peripherals as resources,
> that is, the new baseimg should actually request the wdt3 as any other
> clock.

I see, but if wdt3 is requested as another clock, the Linux ARM side
would still need to know how to threat the WDT.

Cheers.

-- 
Felipe Contreras
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux