Arnd Bergmann wrote:
This is basically ok, but then I think you should pass GFP_DMA
or GFP_DMA32 to all allocations that the driver does after
the 64-bit mask fails, otherwise you get a significant overhead
in the bounce buffers.
Well, for starters, ZONE_DMA32 is the same as ZONE_NORMAL on ARM,
On Wednesday, August 3, 2016 4:24:22 PM CEST Timur Tabi wrote:
> Arnd Bergmann wrote:
> > As I said, this is inherently driver specific. If setting the 64-bit
> > mask fails, the driver itself needs to fall back to the 32-bit mask
> > so it can allocate buffers from ZONE_DMA instead of ZONE_NORMAL.
Arnd Bergmann wrote:
As I said, this is inherently driver specific. If setting the 64-bit
mask fails, the driver itself needs to fall back to the 32-bit mask
so it can allocate buffers from ZONE_DMA instead of ZONE_NORMAL.
I just posted a v7 of my patch, but I forgot to fix the dma_set_mask
ca
Timur Tabi wrote:
Is there a good way to test my code? ping and iperf appear to send no
more than 3 packets at a time, which comes nowhere close to filling the
queue (which holds 512 normally). netif_queue_stopped() never returns
true, no matter what I do.
Never mind, I fixed this problem. I
Lino Sanfilippo wrote:
By looking closer to the code, the lock seems to serve the protection of a list
of skbs that
are queued to be timestamped. However there is nothing that ever enqueues those
skbs, is it?
I assume that this is a leftover of a previous version of that driver. Code to
be me
On 28.07.2016 21:12, Timur Tabi wrote:
>
>>> + if (ret) {
>>> + netdev_err(adpt->netdev,
>>> + "error:%d on request_irq(%d:%s flags:0)\n", ret,
>>> + irq->irq, EMAC_MAC_IRQ_RES);
>>
>> freeing the irq is missing
>
> Will fix.
>
>>> + /* di
Lino Sanfilippo wrote:
+ skb = dev_alloc_skb(adpt->rxbuf_size + NET_IP_ALIGN);
+ if (!skb)
+ break;
+
+ /* Make buffer alignment 2 beyond a 16 byte boundary
+* this will result in a 16 byte aligned IP header after
+
Hi,
some remarks below.
> +/* Fill up receive queue's RFD with preallocated receive buffers */
> +static void emac_mac_rx_descs_refill(struct emac_adapter *adpt,
> + struct emac_rx_queue *rx_q)
> +{
> + struct emac_buffer *curr_rxbuf;
> + struct emac_buffer
On Wednesday, June 29, 2016 3:16:04 PM CEST Timur Tabi wrote:
> Arnd Bergmann wrote:
>
> >> Sure, but in theory, my for-loop is correct, right? Wouldn't there be
> >> some value in setting a 36-bit or 40-bit DMA mask if it works? We have
> >> a platform where memory starts at a 40-bit address, s
Arnd Bergmann wrote:
Sure, but in theory, my for-loop is correct, right? Wouldn't there be
some value in setting a 36-bit or 40-bit DMA mask if it works? We have
a platform where memory starts at a 40-bit address, so some devices have
a 44-bit address bus. If a 64-bit mask doesn't work, then
On Wednesday, June 29, 2016 10:46:23 AM CEST Timur Tabi wrote:
> Arnd Bergmann wrote:
> > Usually drivers try 64-bit mask and 32-bit masks, and the 32 bit
> > mask is practically guaranteed to succeed.
>
> Sure, but in theory, my for-loop is correct, right? Wouldn't there be
> some value in sett
Arnd Bergmann wrote:
Usually drivers try 64-bit mask and 32-bit masks, and the 32 bit
mask is practically guaranteed to succeed.
Sure, but in theory, my for-loop is correct, right? Wouldn't there be
some value in setting a 36-bit or 40-bit DMA mask if it works? We have
a platform where memo
On Wednesday, June 29, 2016 10:10:59 AM CEST Timur Tabi wrote:
> Arnd Bergmann wrote:
> > That's also not how it works: each device starts out with a 32-bit mask,
> > because that's what historically all PCI devices can do. If a device
> > is 64-bit DMA capable, it can extend the mask by passing DM
Arnd Bergmann wrote:
That's also not how it works: each device starts out with a 32-bit mask,
because that's what historically all PCI devices can do. If a device
is 64-bit DMA capable, it can extend the mask by passing DMA_BIT_MASK(64)
(or whatever it can support), and the platform code checks i
On Wednesday, June 29, 2016 9:33:54 AM CEST Timur Tabi wrote:
> Arnd Bergmann wrote:
> > If the ranges property lists the bus as dma capable for only the
> > lower 32 bits, then dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
> > should fail, otherwise dma_alloc_coherent() will return an invalid
Arnd Bergmann wrote:
If the ranges property lists the bus as dma capable for only the
lower 32 bits, then dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
should fail, otherwise dma_alloc_coherent() will return an invalid
memory area.
That seems wrong. dma_alloc_coherent() should be smart eno
On Wednesday, June 29, 2016 7:17:29 AM CEST Timur Tabi wrote:
> Arnd Bergmann wrote:
> > On Friday, June 24, 2016 6:46:48 PM CEST Timur Tabi wrote:
> >> >+ /* The EMAC itself is capable of 64-bit DMA. If the SOC limits
> >> >that
> >> >+* range, then we expect platform code to adjust
Arnd Bergmann wrote:
On Friday, June 24, 2016 6:46:48 PM CEST Timur Tabi wrote:
>+ /* The EMAC itself is capable of 64-bit DMA. If the SOC limits that
>+* range, then we expect platform code to adjust the mask accordingly.
>+*/
>+ ret = dma_set_mask_and_coherent(&pdev
On Friday, June 24, 2016 6:46:48 PM CEST Timur Tabi wrote:
> + /* The EMAC itself is capable of 64-bit DMA. If the SOC limits that
> +* range, then we expect platform code to adjust the mask accordingly.
> +*/
> + ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(
From: Timur Tabi
Date: Fri, 24 Jun 2016 18:46:48 -0500
> + while (test_and_set_bit(EMAC_STATUS_RESETTING, &adpt->status))
> + msleep(20); /* Reset might take few 10s of ms */
...
> + while (test_and_set_bit(EMAC_STATUS_RESETTING, &adpt->status))
> + msleep(20); /*
On Fri, Jun 24, 2016 at 06:46:48PM -0500, Timur Tabi wrote:
> Add supports for ethernet controller HW on Qualcomm Technologies, Inc. SoC.
> This driver supports the following features:
> 1) Checksum offload.
> 2) Interrupt coalescing support.
> 3) SGMII phy.
> 4) phylib interface for external phy
>
Add supports for ethernet controller HW on Qualcomm Technologies, Inc. SoC.
This driver supports the following features:
1) Checksum offload.
2) Interrupt coalescing support.
3) SGMII phy.
4) phylib interface for external phy
Based on original work by
Niranjana Vishwanathapura
Gil
22 matches
Mail list logo
