From: Dean Matsen <deanmatsen@earthlink•net>
To: Wolfgang Denk <wd@denx•de>,
Stephan Linke <Stephan.Linke@epygi•de>,
Linuxppc-Embedded <linuxppc-embedded@lists•linuxppc.org>
Subject: Re: parallel I/O ports & opend darin pins on MPC8xx
Date: Wed, 09 Jul 2003 13:20:58 -0700 [thread overview]
Message-ID: <3F0C792A.7010901@earthlink.net> (raw)
In-Reply-To: 3F0C7782.3060704@earthlink.net
Dean Matsen wrote:
>
> Wolfgang Denk wrote:
>
>> In message <3F0C6C0C.8040306@earthlink•net> you wrote:
>>
>>
>>>> Solution? What is so difficult about latching your output value in a
>>>> variable?
>>>>
>>>>
>>>>
>>> What he's saying is that OTHER drivers read the input and then write
>>> that value to the output.
>>>
>>>
>>
>> I did understand this.
>>
>>
>>
>>> In his driver, he can latch the output through a variable, but that
>>> won't affect what other
>>>
>>>
>>
>> Obviously all drivers that may modify bits in this I/O port will have
>> to share the variable used to latch the value.
>>
>> Yes, this may include modifying existing code in the UART or Ethernet
>> or other drivers.
>>
>>
>>
>>> Unless there is kernel support to alias the data in a memory variable
>>> (and it doesn't sound like
>>> there is), then this is going to continue to be a problem. Might I
>>>
>>>
>>
>> Don't make it unnecessary complicated. You don't need "kernel support
>> to alias the data in a memory variable". This is really not so
>> difficult to implement yourself when you need it.
>>
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>>
>>
> No no, I wasn't suggesting that it be added, I was (subtly) pointing out
> that it is not likely to be added because you'd have to review every
> other driver in the PPC system. Not gonna happen.
>
> But I still don't see how you could avoid having other drivers clobber
> your output but. I think he has to take one of the two options I
> suggested. Adding his own variable can't help in any way I can
> imagine. Could you give an example?
>
> Dean
>
>
>
>
Ooops, NM on the example -- I didn't read carefully enough. Yes,
updating the
other drivers would work too, but then he's got to maintain a ton of patches
for his version of the kernel.
Dean
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-07-09 20:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3F0C6C0C.8040306@earthlink.net>
2003-07-09 19:57 ` parallel I/O ports & opend darin pins on MPC8xx Wolfgang Denk
[not found] ` <3F0C7782.3060704@earthlink.net>
2003-07-09 20:17 ` Wolfgang Denk
2003-07-09 20:20 ` Dean Matsen [this message]
[not found] <FCEAKDJJAPHPLJFINDAJEEGGDEAA.Stephan.Linke@epygi.de>
2003-07-09 12:09 ` Wolfgang Denk
[not found] <FCEAKDJJAPHPLJFINDAJCEGCDEAA.Stephan.Linke@epygi.de>
2003-07-09 10:24 ` Wolfgang Denk
2003-07-08 15:31 Stephan Linke
2003-07-08 15:49 ` Craig Hollabaugh
2003-07-08 21:36 ` Wolfgang Denk
2003-07-09 4:57 ` None Atall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F0C792A.7010901@earthlink.net \
--to=deanmatsen@earthlink$(echo .)net \
--cc=Stephan.Linke@epygi$(echo .)de \
--cc=linuxppc-embedded@lists$(echo .)linuxppc.org \
--cc=wd@denx$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox