Mike,
On Thu, Jan 27, 2011 at 12:41 AM, Mike Rapoport wrote:
> Tom,
>
> On 01/26/11 19:05, Tom Warren wrote:
>> Mike,
>>
>> On Wed, Jan 26, 2011 at 1:13 AM, Mike Rapoport wrote:
>>> My point was that pin muxing belongs to the board code rather than to the
>>> driver. Driver should just assume th
On 01/26/11 17:58, Peter Tyser wrote:
> On Wed, 2011-01-26 at 10:13 +0200, Mike Rapoport wrote:
>> On 01/26/11 00:24, Peter Tyser wrote:
>
>> Moreover, I'd prefer to see pinmux_board_init or something similar that
>> configures all the pins at once rather than collection of pinmux_init_uart,
>> pi
Tom,
On 01/26/11 19:05, Tom Warren wrote:
> Mike,
>
> On Wed, Jan 26, 2011 at 1:13 AM, Mike Rapoport wrote:
>> My point was that pin muxing belongs to the board code rather than to the
>> driver. Driver should just assume that pins are configured elsewhere and it
>> does
>> not need to deal wit
Mike,
On Wed, Jan 26, 2011 at 1:13 AM, Mike Rapoport wrote:
> On 01/26/11 00:24, Peter Tyser wrote:
>>> As I've already pointed out (1) this covers only one possibility of
>>> UART pin
>>> muxing options. I agree that it makes sense when this is a part of the
>>> board-specific c
On Wed, 2011-01-26 at 10:13 +0200, Mike Rapoport wrote:
> On 01/26/11 00:24, Peter Tyser wrote:
> >> As I've already pointed out (1) this covers only one possibility of
> >> UART pin
> >> muxing options. I agree that it makes sense when this is a part of the
> >> board-specific cod
On 01/26/11 00:24, Peter Tyser wrote:
>> As I've already pointed out (1) this covers only one possibility of UART
>> pin
>> muxing options. I agree that it makes sense when this is a part of the
>> board-specific code. However, forcing specific pins configuration in the
>> gen
> [ snip ]
>
> > +/*
> > + * Routine: pin_mux_uart
> > + * Description: setup the pin muxes/tristate values for a UART
> > + */
> > +static void pin_mux_uart(void)
> > +{
> > + pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr
> > *)NV_PA_APB_MISC_BASE;
>
Mike et al,
On Tue, Jan 25, 2011 at 2:37 PM, Tom Warren wrote:
> Mike,
>
> On Tue, Jan 25, 2011 at 2:12 PM, Mike Rapoport wrote:
>> On 01/25/11 18:50, Tom Warren wrote:
>>> Mike,
>>>
>>> On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport wrote:
On 01/22/11 01:06, Tom Warren wrote:
> Signed
Mike,
On Tue, Jan 25, 2011 at 2:12 PM, Mike Rapoport wrote:
> On 01/25/11 18:50, Tom Warren wrote:
>> Mike,
>>
>> On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport wrote:
>>> On 01/22/11 01:06, Tom Warren wrote:
Signed-off-by: Tom Warren
---
>>>
>>> [ snip ]
>>>
+/*
+ * Routine
On 01/25/11 18:50, Tom Warren wrote:
> Mike,
>
> On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport wrote:
>> On 01/22/11 01:06, Tom Warren wrote:
>>> Signed-off-by: Tom Warren
>>> ---
>>
>> [ snip ]
>>
>>> +/*
>>> + * Routine: pin_mux_uart
>>> + * Description: setup the pin muxes/tristate values fo
Mike,
On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport wrote:
> On 01/22/11 01:06, Tom Warren wrote:
>> Signed-off-by: Tom Warren
>> ---
>
> [ snip ]
>
>> +/*
>> + * Routine: pin_mux_uart
>> + * Description: setup the pin muxes/tristate values for a UART
>> + */
>> +static void pin_mux_uart(void)
On 01/22/11 01:06, Tom Warren wrote:
> Signed-off-by: Tom Warren
> ---
[ snip ]
> +/*
> + * Routine: pin_mux_uart
> + * Description: setup the pin muxes/tristate values for a UART
> + */
> +static void pin_mux_uart(void)
> +{
> + pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr *)NV_PA_APB_MISC
Peter,
On Mon, Jan 24, 2011 at 12:14 PM, Peter Tyser wrote:
>
>
>> I see what you're talking about now - I've got uart.c in 2 patch files -
>> created
>> in 0001 and then moved in 0002. My bad - that wasn't the intent, just what
>> happened when I applied my V4 patches to a new branch to get th
> I see what you're talking about now - I've got uart.c in 2 patch files -
> created
> in 0001 and then moved in 0002. My bad - that wasn't the intent, just what
> happened when I applied my V4 patches to a new branch to get the V5 patchset
> built. I'll fix it and resubmit.
>
> As to 0002 not
Dear Tom Warren,
In message you
wrote:
>
> Correct, again (need more coffee!) Your if defined construct wouldn't work
> as written, though, because CONFIG_TEGRA2_ENABLE_UARTx is always
> defined (as 0 or 1). I'd have to rework it.
Please try and avoid relying on specific values.
Rather use "#
Dear Peter Tyser,
In message <1295891506.2045.146.camel@petert> you wrote:
>
> > I'll use those options in the future (thanks!) to keep things cleaner.
> > Hopefully we can just go with this set of patches so I can get to the
> > other, more interesting code (drivers, A9 CPU init, etc.).
>
> Its
Peter,
On Mon, Jan 24, 2011 at 10:51 AM, Peter Tyser wrote:
>
>
>> > It looks like arch/arm/cpu/armv7/tegra2/board.h and
>> > arch/arm/cpu/armv7/tegra2/uart.c are added in the first patch, then
>> > moved in this patch. It'd be ideal to just add them once in the proper
>> > location.
>> >
>> >
> > It looks like arch/arm/cpu/armv7/tegra2/board.h and
> > arch/arm/cpu/armv7/tegra2/uart.c are added in the first patch, then
> > moved in this patch. It'd be ideal to just add them once in the proper
> > location.
> >
> > On a side note, if you pass "git format-patch" the -M and -C options it
Peter,
On Fri, Jan 21, 2011 at 4:46 PM, Peter Tyser wrote:
> Hi Tom,
>
> On Fri, 2011-01-21 at 16:06 -0700, Tom Warren wrote:
>> Signed-off-by: Tom Warren
>> ---
>> Changes for V2:
>> - Move serial driver to separate patch
>>
>> Changes for V5:
>> - Move arch/arm/cpu/armv7/uart.c & b
Hi Tom,
On Fri, 2011-01-21 at 16:06 -0700, Tom Warren wrote:
> Signed-off-by: Tom Warren
> ---
> Changes for V2:
> - Move serial driver to separate patch
>
> Changes for V5:
> - Move arch/arm/cpu/armv7/uart.c & board.h to drivers/serial and
> rename to serial_tegra2.c
>
Signed-off-by: Tom Warren
---
Changes for V2:
- Move serial driver to separate patch
Changes for V5:
- Move arch/arm/cpu/armv7/uart.c & board.h to drivers/serial and
rename to serial_tegra2.c
- Remove use of uart_num & UART_A/D in serial_tegra2, simplify co
21 matches
Mail list logo
