Arnd Bergmann wrote:
> In that case, I think the right solution would be to have different properties
> in the device tree, depending on whether or not you have a soft-uart and
> whether
> you need to download the microcode.
> Having only a compile time option is very bad because it prevents you
On Wed, 5 Dec 2007 00:56:39 +0100
Arnd Bergmann wrote:
> On Wednesday 05 December 2007, Timur Tabi wrote:
> > Arnd Bergmann wrote:
> >
> > > You can argue that the QS is really a DMA device, but in that
> > > case you should convert the driver to use the DMA mapping
> > > interfaces correctly, wh
On Wednesday 05 December 2007, Timur Tabi wrote:
> Arnd Bergmann wrote:
>
> > You can argue that the QS is really a DMA device, but in that case you
> > should convert the driver to use the DMA mapping interfaces correctly,
> > which I would consider overkill.
>
> I'm confused. I'm already calli
Arnd Bergmann wrote:
> You can argue that the QS is really a DMA device, but in that case you
> should convert the driver to use the DMA mapping interfaces correctly,
> which I would consider overkill.
I'm confused. I'm already calling dma_alloc_coherent() and getting a
dma_addr_t
back. Why d
Arnd Bergmann wrote:
> On Wednesday 05 December 2007, Scott Wood wrote:
>>> You can argue that the QS is really a DMA device, but in that
>>> case you should convert the driver to use the DMA mapping
>>> interfaces correctly, which I would consider overkill.
>> Why is it overkill?
>>
>
> Well, if
On Wednesday 05 December 2007, Scott Wood wrote:
>
> > You can argue that the QS is really a DMA device, but in that case you
> > should convert the driver to use the DMA mapping interfaces correctly,
> > which I would consider overkill.
>
> Why is it overkill?
>
Well, if the QE can never be us
Arnd Bergmann wrote:
> From a code clarity perspective, the interesting point is that dma_addr_t is
> what comes back from the functions in dma-mapping.h. If you don't use them,
> a physical address is phys_addr_t.
>
> You can argue that the QS is really a DMA device, but in that case you
> should
On Tuesday 04 December 2007, Timur Tabi wrote:
> When I program the DMA controller, I give it a dma_addr_t. And yet, the DMA
> controller and the QE are both devices on the SoC. So if the DMA controller
> takes a dma_addr_t, then shouldn't the QE also take one?
>
>From a code clarity perspect
Arnd Bergmann wrote:
> I'm guessing that you don't really mean dma_addr_t here, but rather
> phys_addr_t, which is something different.
Now that I think about it, I don't know which is correct. The value is plugged
into the pointer register of a buffer descriptor, and the QE performs a
DMA-lik
Arnd Bergmann wrote:
> Can you use the driver on CPUs without this particular bug when it's built
> in Soft-UART mode?
No, you have to build with Soft-UART mode turned off. Soft-UART mode actually
uses the HMC mode of the QE and hacks it up to act like a UART.
The only way to know at runtime w
On Tuesday 04 December 2007, Timur Tabi wrote:
> Add support for UART serial ports using a Freescale QUICC Engine
> (found on some MPC83xx and MPC85xx SOCs).
>
> Because of a silicon bug in some QE-enabled SOCs (e.g. 8323 and 8360), a new
> microcode is required. This microcode implements UART via
11 matches
Mail list logo
