0_CNFG_GPIO_INPUT_VAL_MASK);
> + else
> + return !!(val & MAX77620_CNFG_GPIO_OUTPUT_VAL_MASK);
Looks sensible!
Reviewed-by: Alexandre Courbot
Add the VDD_GPU regulator (a GPIO-enabled PWM regulator) to the Jetson
TX1 board. This addition allows the GPU to be used provided the
bootloader properly enabled the GPU node.
Signed-off-by: Alexandre Courbot
---
Changes since v1:
- Include this patch into the series to make sure it is merged
Add an optional enable GPIO to the pwm-regulator driver.
Signed-off-by: Alexandre Courbot
---
Changes since v1:
- Do not try to be smart and use the core enable GPIO as this introduces an
incompatible behavior. Probe and manipulate the GPIO in pwm-regulator.
- Use standard enable-gpios name
On Thu, Jun 23, 2016 at 10:10 AM, Alexandre Courbot wrote:
> On Wed, Jun 22, 2016 at 7:34 PM, Mark Brown wrote:
>> On Wed, Jun 22, 2016 at 05:25:53PM +0900, Alexandre Courbot wrote:
>>> The current regulator enable/disable mechanism does not call the driver
>>> ena
On Wed, Jun 22, 2016 at 7:34 PM, Mark Brown wrote:
> On Wed, Jun 22, 2016 at 05:25:53PM +0900, Alexandre Courbot wrote:
>> The current regulator enable/disable mechanism does not call the driver
>> enable/disable op if an enable GPIO is set. It may be desirable to use
>> b
If instanciated from the DT, use of_get_regulator_gpio_config to obtain
the enable GPIO configuration.
Signed-off-by: Alexandre Courbot
---
drivers/regulator/fixed.c | 52 ---
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers
Several regulator drivers are using an enable GPIO with similar DT
properties, yet each driver is parsing these properties its own way. Add
the of_get_regulator_gpio_config() function which is able to parse all
known properties and update the regulator_config accordingly.
Signed-off-by: Alexandre
Enable the pwm-regulator driver to make use of an enable GPIO.
Signed-off-by: Alexandre Courbot
---
drivers/regulator/pwm-regulator.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/regulator/pwm-regulator.c
b/drivers/regulator/pwm-regulator.c
index ab3cc0235843..8e5e4e744c51
If instanciated from the DT, use of_get_regulator_gpio_config to obtain
the enable GPIO configuration.
Signed-off-by: Alexandre Courbot
---
drivers/regulator/gpio-regulator.c | 47 --
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/drivers
enable
conditions into account.
Signed-off-by: Alexandre Courbot
---
drivers/regulator/core.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index db320e8fa865..995706070906 100644
--- a
Add and document the enable-gpio property. Its behavior is similar to
the property of the same name found in GPIO regulator and fixed
regulator.
Cc: devicet...@vger.kernel.org
Signed-off-by: Alexandre Courbot
---
Documentation/devicetree/bindings/regulator/pwm-regulator.txt | 7 ++-
1 file
.
Finally patches 5-6 add support for the enable GPIO in pwm-regulator and the
corresponding DT binding. The binding is kept minimal (active-high and
open-drain properties can be specified in the GPIO phandle) on purpose.
Alexandre Courbot (6):
regulator: core: Allow simultaneous use of enable op
Colin Pitrat
Besides fixing the issue, avoiding an upcast from gpio_chip in
functions that are not driver hooks seems a good practice to me.
Acked-by: Alexandre Courbot
On 06/16/2016 03:35 PM, Viresh Kumar wrote:
+Rafael
On 16-06-16, 14:35, Alexandre Courbot wrote:
This is not an actual request for revert, but rather for comments about
the observed behavior since I am not really familiar with cpufreq.
I am observing a serious performance regression on Jetson
;).
Fixes: 6f707daa3833 ("PM / OPP: Add dev_pm_opp_get_sharing_cpus()")
Reported-by: Alexandre Courbot
Signed-off-by: Viresh Kumar
---
Hi Alexandre,
This is untested, can you please confirm if this fixes it for you?
Yep, with this cpufreq_init() takes the fallback path and cpufreq
behave
This is not an actual request for revert, but rather for comments about
the observed behavior since I am not really familiar with cpufreq.
I am observing a serious performance regression on Jetson TK1 since 4.7-rc1:
namely, moving windows under X would become unsufferably slow, and graphical
perfo
7;s Acks.
>>
>
> I don't see this in linux-next yet (as of 20160614). Can we get this
> merged there to.
Was about to say the same thing. FWIW:
Tested-by: Alexandre Courbot
On Tue, Jun 7, 2016 at 8:44 PM, Laxman Dewangan wrote:
> Jetson-TX1 uses the Maxim MAX77620 as system Power management IC.
> Add device node for the MAX77620 with following details:
> - Add device max77620 with.
> - Add all pins configurations.
> - Configure FPS of the device.
>
tch set looks good to me, Alexandre is this OK with you?
Sorry! This look good to me, yes.
Acked-by: Alexandre Courbot
On Thursday, May 12, 2016 10:07:06 PM JST, Christian Lamparter wrote:
On Thursday, May 12, 2016 07:30:05 PM Alexandre Courbot wrote:
On Wednesday, May 11, 2016 6:34:35 PM JST, Christian Lamparter wrote: ...
[...]
...
Ouch, I don't like this. Also the probability that the "if (
On Thu, May 12, 2016 at 9:07 PM, Christian Lamparter
wrote:
> On Thursday, May 12, 2016 07:26:32 PM Alexandre Courbot wrote:
>> On Wednesday, May 11, 2016 6:34:34 PM JST, Christian Lamparter wrote:
>> > From: Álvaro Fernández Rojas
>> >
>> > This patch add
On Wednesday, May 11, 2016 6:34:35 PM JST, Christian Lamparter wrote:
This patch integrates the GPIO drivers for the following
boards, SoCs, etc. into gpio-mmio:
- CLPS711X SoCs
- MOXA ART SoC
- TS-4800 FPGA DIO blocks and compatibles
- GPIO controllers found on some GE Single Board Computers
On Wednesday, May 11, 2016 6:34:34 PM JST, Christian Lamparter wrote:
From: Álvaro Fernández Rojas
This patch adds support for defining memory-mapped GPIOs which
are compatible with the existing gpio-mmio interface. The generic
library provides support for many memory-mapped GPIO controllers
th
axman Dewangan
> Reviewed-by: Stephen Warren
Reviewed-by: Alexandre Courbot
Sorry, just realized I commented on v3...
On Fri, Apr 22, 2016 at 7:09 PM, Laxman Dewangan wrote:
> NVIDIA's Tegra210 support the HW debounce in the GPIO controller
> for all its GPIO pins.
>
> Add support for setting debounce timing by implementing the
> set_debounce callback of gpiochip.
>
> Si
s);
> + NULL, tgi, &debug_fops);
> }
>
> #else
>
> -static inline void tegra_gpio_debuginit(void)
> +static inline void tegra_gpio_debuginit(struct tegra_gpio_info *tgi)
> {
> }
>
> @@ -458,6 +507,7 @@ static struct lock_class_key gpio_lock_class;
> static int tegra_gpio_probe(struct platform_device *pdev)
> {
> const struct tegra_gpio_soc_config *config;
> + struct tegra_gpio_info *tgi;
> struct resource *res;
> struct tegra_gpio_bank *bank;
> int ret;
> @@ -465,79 +515,85 @@ static int tegra_gpio_probe(struct platform_device
> *pdev)
> int i;
> int j;
>
> - dev = &pdev->dev;
> -
> config = of_device_get_match_data(&pdev->dev);
> if (!config) {
> dev_err(&pdev->dev, "Error: No device match found\n");
> return -ENODEV;
> }
>
> - tegra_gpio_bank_stride = config->bank_stride;
> - tegra_gpio_upper_offset = config->upper_offset;
> + tgi = devm_kzalloc(&pdev->dev, sizeof(*tgi), GFP_KERNEL);
> + if (!tgi)
> + return -ENODEV;
> +
> + tgi->soc = config;
> + tgi->dev = &pdev->dev;
>
> for (;;) {
> - res = platform_get_resource(pdev, IORESOURCE_IRQ,
> tegra_gpio_bank_count);
> + res = platform_get_resource(pdev, IORESOURCE_IRQ,
> + tgi->bank_count);
> if (!res)
> break;
> - tegra_gpio_bank_count++;
> + tgi->bank_count++;
> }
> - if (!tegra_gpio_bank_count) {
> + if (!tgi->bank_count) {
> dev_err(&pdev->dev, "Missing IRQ resource\n");
> return -ENODEV;
> }
>
> - tegra_gpio_chip.ngpio = tegra_gpio_bank_count * 32;
> + tgi->gc = &tegra_gpio_chip;
> + tgi->gc->ngpio = tgi->bank_count * 32;
> + tgi->gc->parent = &pdev->dev;
> + tgi->gc->of_node = pdev->dev.of_node;
As said in 4/4, I really think gc should not be a pointer so several
instances can coexist. Most other GPIO drivers follow this model.
With these small details fixed, I believe this looks good!
Reviewed-by: Alexandre Courbot
On Wed, Apr 20, 2016 at 10:30 PM, Laxman Dewangan wrote:
> NVIDIA's Tegra210 support the HW debounce in the GPIO
> controller for all its GPIO pins.
>
> Add support for setting debounce timing by implementing the
> set_debounce callback of gpiochip.
>
> Signed-off-by: Laxman Dewangan
>
> ---
> Ch
On 04/11/2016 04:22 PM, Alexandre Courbot wrote:
Hi Robin,
On 04/09/2016 03:46 AM, Robin Murphy wrote:
Hi Alex,
On 08/04/16 05:47, Alexandre Courbot wrote:
Hi Robin,
On 04/07/2016 08:50 PM, Robin Murphy wrote:
Hello,
With 4.6-rc2 (and -rc1) I'm seeing Nouveau blowing up at boot, fro
n the file's global namespace is
scary and prone to conflict with local variables declarations.
Acked-by: Alexandre Courbot
Now I hope you will take care of "regs" and the other static variables
as Stephen rightfully suggested. :)
On Mon, Apr 18, 2016 at 5:46 PM, Laxman Dewangan wrote:
> Use of_device_get_match_data() for getting matched data
> instead of implementing this locally.
Maybe this is moving things around more than needed, but the end
result is arguably nicer.
Reviewed-by: Alexandre Courbot
On 04/11/2016 04:22 PM, Alexandre Courbot wrote:
... or maybe we could just unconditionally sync all buffers and let the
DMA API abstract this away. My concern is that on coherent architectures
we would still need to loop over all the pages for nothing, as I don't
think the loop (se
Hi Robin,
On 04/09/2016 03:46 AM, Robin Murphy wrote:
Hi Alex,
On 08/04/16 05:47, Alexandre Courbot wrote:
Hi Robin,
On 04/07/2016 08:50 PM, Robin Murphy wrote:
Hello,
With 4.6-rc2 (and -rc1) I'm seeing Nouveau blowing up at boot, from the
look of it by dereferencing some offset from
Hi Robin,
On 04/07/2016 08:50 PM, Robin Murphy wrote:
Hello,
With 4.6-rc2 (and -rc1) I'm seeing Nouveau blowing up at boot, from the
look of it by dereferencing some offset from NULL inside
nouveau_fbcon_imageblit(). My setup is an old XFX 7600GT card plugged
into an ARM Juno r1 board, which wo
On Wed, Mar 30, 2016 at 6:16 PM, Guenter Roeck wrote:
> On 03/30/2016 01:37 AM, Alexandre Courbot wrote:
>>
>> On Wed, Mar 30, 2016 at 3:20 AM, Guenter Roeck wrote:
>>>
>>> Since commit ff2b13592299 ("gpio: make the gpiochip a real device"),
>&
On Wed, Mar 30, 2016 at 3:20 AM, Guenter Roeck wrote:
> Since commit ff2b13592299 ("gpio: make the gpiochip a real device"),
> attempts to add a gpio chip prior to gpiolib initialization cause the
> system to crash. Dump a warning to the console and return an error
> if the situation is encountere
This clock is required for the GPU to operate.
Signed-off-by: Alexandre Courbot
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index
The correct compatible name is "nvidia,gk20a".
Signed-off-by: Alexandre Courbot
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk
GK20A can optionally make use of an IOMMU.
Signed-off-by: Alexandre Courbot
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
b/Documentation
Nouveau can take advantage of this declaration to remove the need for
contiguous memory.
Signed-off-by: Alexandre Courbot
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia
GM20B's definition is mostly similar to GK20A's, but requires an
additional clock.
Signed-off-by: Alexandre Courbot
Acked-by: Rob Herring
---
.../devicetree/bindings/gpu/nvidia,gk20a.txt | 29 +++---
1 file changed, 26 insertions(+), 3 deletions(-)
di
- Carried Acked-bys
Changes since v1:
- Renamed "pllg_ref" clock to "ref" in DT bindings
Alexandre Courbot (5):
dt-bindings: gk20a: Fix typo in compatible name
dt-bindings: gk20a: Document iommus property
dt-bindings: Add documentation for GM20B GPU
arm64: tegra210: Ad
On 03/22/2016 10:41 AM, Rob Herring wrote:
On Sun, Mar 20, 2016 at 1:55 AM, Alexandre Courbot wrote:
On Sat, Mar 19, 2016 at 5:47 AM, Rob Herring wrote:
On Tue, Mar 15, 2016 at 11:58:42AM +0900, Alexandre Courbot wrote:
GM20B's definition is mostly similar to GK20A's, but r
On Sat, Mar 19, 2016 at 5:47 AM, Rob Herring wrote:
> On Tue, Mar 15, 2016 at 11:58:42AM +0900, Alexandre Courbot wrote:
>> GM20B's definition is mostly similar to GK20A's, but requires an
>> additional clock.
>>
>> Signed-off-by: Alexandre Courbot
>>
On Sat, Mar 19, 2016 at 5:31 AM, Rob Herring wrote:
> On Tue, Mar 15, 2016 at 11:58:40AM +0900, Alexandre Courbot wrote:
>> The correct compatible name is "nvidia,gk20a".
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> Documentation/devicetree/bindin
On Fri, Mar 18, 2016 at 7:58 PM, Russell King - ARM Linux
wrote:
> On Fri, Mar 18, 2016 at 06:28:49PM +0900, Alexandre Courbot wrote:
>> Commit 19e6e5e5392b ("ARM: 8547/1: dma-mapping: store buffer
>> information") allocates a structure meant for internal buffer managem
_SLAB_BUG_MASK)) {
pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
BUG();
}
Fix this by filtering the flags that make the slab allocator unhappy.
Signed-off-by: Alexandre Courbot
Cc: Rabin Vincent
---
Changes since v1:
- Filter flags that may caus
_SLAB_BUG_MASK)) {
pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
BUG();
}
Fix this by allocating the structure with GFP_KERNEL, as it is meant to
be used by the kernel and not for DMA.
Signed-off-by: Alexandre Courbot
---
arch/arm/mm/dma-mapping
On 03/18/2016 05:05 PM, Rabin Vincent wrote:
On Fri, Mar 18, 2016 at 11:12:26AM +0900, Alexandre Courbot wrote:
Commit 19e6e5e5392b ("ARM: 8547/1: dma-mapping: store buffer
information") allocates a structure meant for internal buffer management
with the GFP flags of the buffer itself
GM20B's definition is mostly similar to GK20A's, but requires an
additional clock.
Signed-off-by: Alexandre Courbot
---
.../devicetree/bindings/gpu/nvidia,gk20a.txt | 27 --
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/
The correct compatible name is "nvidia,gk20a".
Signed-off-by: Alexandre Courbot
---
Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
b/Documentation/
Small series that fixes/completes DT bindings for Tegra GPUs and add two
missing entries required for the Tegra210 GPU to operate properly.
Changes since v1:
- Renamed "pllg_ref" clock to "ref" in DT bindings
Alexandre Courbot (5):
dt-bindings: gk20a: Fix typo in compatibl
This clock is required for the GPU to operate.
Signed-off-by: Alexandre Courbot
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index
GK20A can optionally make use of an IOMMU.
Signed-off-by: Alexandre Courbot
---
Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
b/Documentation/devicetree/bindings/gpu/nvidia
Nouveau can take advantage of this declaration to remove the need for
contiguous memory.
Signed-off-by: Alexandre Courbot
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia
On Tue, Mar 8, 2016 at 10:18 PM, Adrian Hunter wrote:
> On 07/03/16 04:07, Alexandre Courbot wrote:
>> DMA mask will already be set by sdhci_set_dma_mask(), which
>> is equivalent to the removed code since pci_set_dma_mask()
>> expands to its DMA-API counterpart.
>>
GK20A can optionally make use of an IOMMU.
Signed-off-by: Alexandre Courbot
---
Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
b/Documentation/devicetree/bindings/gpu/nvidia
GM20B's definition is mostly similar to GK20A's, but requires an
additional clock.
Signed-off-by: Alexandre Courbot
---
.../devicetree/bindings/gpu/nvidia,gk20a.txt | 27 --
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/
The correct compatible name is "nvidia,gk20a".
Signed-off-by: Alexandre Courbot
---
Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
b/Documentation/
Small series that fixes/completes DT bindings for Tegra GPUs and add two
missing entries required for the Tegra210 GPU to operate properly.
Alexandre Courbot (5):
dt-bindings: gk20a: Fix typo in compatible name
dt-bindings: gk20a: Document iommus property
dt-bindings: Add documentation for
This clock is required for the GPU to operate.
Signed-off-by: Alexandre Courbot
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index
Nouveau can take advantage of this declaration to remove the need for
contiguous memory.
Signed-off-by: Alexandre Courbot
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia
On Fri, Feb 26, 2016 at 5:36 PM, Alexandre Courbot wrote:
> arm_dma_set_mask() implements exactly the same behavior as the fallback
> that dma_set_mask() takes if the set_dma_mask op is not set. Remove it
> and use that fallback instead like the dma_get_mask() counterpart
> already d
d-bys
Alexandre Courbot (3):
mmc: sdhci: Set DMA mask when adding host
mmc: sdhci-acpi: Remove enable_dma() hook
mmc: sdhci-pci: Do not set DMA mask in enable_dma()
drivers/mmc/host/sdhci-acpi.c | 30
drivers/mmc/host/sdhci-pci-core.c | 15
drivers/mmc
DMA mask will already be set by sdhci_set_dma_mask(), which
is equivalent to the removed code since pci_set_dma_mask()
expands to its DMA-API counterpart.
There should also be no reason to set the DMA mask after probe.
Signed-off-by: Alexandre Courbot
Acked-by: Arnd Bergmann
---
drivers/mmc
This hook was solely used to set the DMA mask, which is now done
by the newly-added sdhci_set_dma_mask() function.
The use of a flag to ensure the mask is only set once is a strong hint
that it should not have been done there anyway.
Signed-off-by: Alexandre Courbot
Acked-by: Arnd Bergmann
: Alexandre Courbot
---
drivers/mmc/host/sdhci.c | 48 +---
1 file changed, 41 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index fd9139947fa3..920e1c996280 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers
On Sat, Mar 5, 2016 at 12:57 AM, Arnd Bergmann wrote:
> On Friday 04 March 2016 19:38:43 Alexandre Courbot wrote:
>> Set the DMA mask in sdhci_add_host() after we determined the
>> capabilities of the device. 64-bit devices in particular are given the
>> proper mask that e
This hook was solely used to set the DMA mask, which is now done
by the newly-added sdhci_set_dma_mask() function.
The use of a flag to ensure the mask is only set once is a strong hint
that it should not have been done there anyway.
Signed-off-by: Alexandre Courbot
---
drivers/mmc/host/sdhci
instead of just Tegra
- Remove supposedly-redundant code from the sdhci-acpi and sdhci-pci drivers
Alexandre Courbot (3):
mmc: sdhci: Set DMA mask when adding host
mmc: sdhci-acpi: Remove enable_dma() hook
mmc: sdhci-pci: Do not set DMA mask in enable_dma()
drivers/mmc/host/sdhci-acpi.
: Alexandre Courbot
---
drivers/mmc/host/sdhci.c | 46 +++---
1 file changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index fd9139947fa3..00fb45ba6f39 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers
DMA mask will already be set by sdhci_set_dma_mask(), which
is equivalent to the removed code since pci_set_dma_mask()
expands to its DMA-API counterpart.
There should also be no reason to set the DMA mask after probe.
Signed-off-by: Alexandre Courbot
---
drivers/mmc/host/sdhci-pci-core.c | 15
On Fri, Mar 4, 2016 at 3:08 PM, Alexandre Courbot wrote:
> On Wed, Mar 2, 2016 at 8:25 PM, Arnd Bergmann wrote:
>> On Wednesday 02 March 2016 19:36:23 Alexandre Courbot wrote:
>>> On Wed, Mar 2, 2016 at 6:34 AM, Arnd Bergmann wrote:
>>> > On Tuesday 01 March 2
On Wed, Mar 2, 2016 at 6:30 AM, Arnd Bergmann wrote:
> On Tuesday 01 March 2016 13:32:43 Alexandre Courbot wrote:
>> */
>> - if (!(host->flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA))) {
>> + if (!(host->flags & (SDHCI_USE_SDMA | SDHCI_
On Wed, Mar 2, 2016 at 8:25 PM, Arnd Bergmann wrote:
> On Wednesday 02 March 2016 19:36:23 Alexandre Courbot wrote:
>> On Wed, Mar 2, 2016 at 6:34 AM, Arnd Bergmann wrote:
>> > On Tuesday 01 March 2016 13:32:44 Alexandre Courbot wrote:
>> >> On T210, the sdhci contr
On Wed, Mar 2, 2016 at 6:34 AM, Arnd Bergmann wrote:
> On Tuesday 01 March 2016 13:32:44 Alexandre Courbot wrote:
>> On T210, the sdhci controller can address more than 32 bits of address
>> space. Failing to express this fact results in the use of bounce
>> buffers an
ommon code
- Set the capabilities of the various Tegra controllers
Alexandre Courbot (2):
mmc: sdhci: Set DMA mask
mmc: sdhci-tegra: Specify valid DMA mask
drivers/mmc/host/sdhci-tegra.c | 8
drivers/mmc/host/sdhci.c | 8 +---
2 files changed, 13 insertions(+), 3 dele
Set the DMA mask if specified by the host's dma_mask member, and
not only if the DMA flags are set.
Use dma_set_mask_and_coherent() to set it instead of messing directly
with the device's dma_mask.
Signed-off-by: Alexandre Courbot
---
drivers/mmc/host/sdhci.c | 8 +---
1 file
On T210, the sdhci controller can address more than 32 bits of address
space. Failing to express this fact results in the use of bounce
buffers and affects performance.
Signed-off-by: Alexandre Courbot
---
drivers/mmc/host/sdhci-tegra.c | 8
1 file changed, 8 insertions(+)
diff --git
On 02/26/2016 08:31 PM, Arnd Bergmann wrote:
On Friday 26 February 2016 16:24:34 Alexandre Courbot wrote:
On Thu, Feb 25, 2016 at 11:52 PM, Arnd Bergmann wrote:
Actually even if we specify a dma-ranges on the parent DT node, the
DMA range will still be limited to 32 bits because of the
operations are set.
Suggested-by: Thierry Reding
Signed-off-by: Alexandre Courbot
---
drivers/gpu/host1x/bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index c2e7fba370bb..c27858ae0552 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers
The default DMA mask covers a 32 bits address range, but host1x devices
can address a larger range on TK1 and TX1. Set the DMA mask to the range
addressable when we use the IOMMU to prevent the use of bounce buffers.
Signed-off-by: Alexandre Courbot
---
Change since v3:
- Use the IOMMU
arm_dma_set_mask() implements exactly the same behavior as the fallback
that dma_set_mask() takes if the set_dma_mask op is not set. Remove it
and use that fallback instead like the dma_get_mask() counterpart
already does.
Signed-off-by: Alexandre Courbot
---
arch/arm/include/asm/dma-mapping.h
On Thu, Feb 25, 2016 at 11:52 PM, Arnd Bergmann wrote:
>> Actually even if we specify a dma-ranges on the parent DT node, the
>> DMA range will still be limited to 32 bits because of the following
>> code in of_dma_configure():
>>
>> /*
>> * Set default coherent_dma_mask to 32 bit. Drive
The default DMA mask covers a 32 bits address range, but devices can
address more than that. Set the DMA mask to the actual addressable range
to avoid the use of unneeded bounce buffers.
Signed-off-by: Alexandre Courbot
---
Changes since v1:
- set the mask at the bus level so of_dma_configure
operations are set.
Suggested-by: Thierry Reding
Signed-off-by: Alexandre Courbot
---
Changes since v2:
- Re-roll with patch 2/2 for completeness
drivers/gpu/host1x/bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index c2e7fba370bb
On Wed, Feb 24, 2016 at 9:37 PM, Arnd Bergmann wrote:
> On Wednesday 24 February 2016 18:11:19 Alexandre Courbot wrote:
>> On T210, the sdhci controller can address more than 32 bits of address
>> space. Failing to express this fact results in the use of bounce
>> buffers an
On T210, the sdhci controller can address more than 32 bits of address
space. Failing to express this fact results in the use of bounce
buffers and affects performance.
Signed-off-by: Alexandre Courbot
---
I am pretty sure this one is wrong in some way, but just to get the ball
rolling as the
operations are set.
Suggested-by: Thierry Reding
Signed-off-by: Alexandre Courbot
---
drivers/gpu/host1x/bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index c2e7fba370bb..c27858ae0552 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers
On 02/24/2016 01:04 AM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Feb 23, 2016 at 03:25:54PM +0900, Alexandre Courbot wrote:
The default DMA mask covers a 32 bits address range, but tegradrm can
address more than that. Set the DMA mask to the actual addressable range
to
On 02/24/2016 12:28 AM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Feb 23, 2016 at 03:25:53PM +0900, Alexandre Courbot wrote:
The current settings leaves the DRM device's dma_ops field NULL, which
makes it use the dummy DMA ops on arm64 and return an error whenever we
t
() is called and sets the default ioswtlb DMA ops.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/tegra/drm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d347188bf8f4..bc0555adecaf 100644
--- a/drivers/gpu/drm/tegra/drm.c
The default DMA mask covers a 32 bits address range, but tegradrm can
address more than that. Set the DMA mask to the actual addressable range
to avoid the use of unneeded bounce buffers.
Signed-off-by: Alexandre Courbot
---
Thierry, I am not absolutely sure whether the size is correct and
On Fri, Jan 29, 2016 at 4:44 AM, Alban Bedel wrote:
> As we now allow the driver to be built as a module it should be
> removable.
>
> Signed-off-by: Alban Bedel
> ---
> drivers/gpio/gpio-ath79.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpio/gpio-ath79.c b/dri
nsertions(+), 113 deletions(-)
Nice, much less code!
Acked-by: Alexandre Courbot
$ echo 496 > unexport
What we *really* ought to do is have GPIOs behave like other resources
and be automatically freed when the application using them exits. This
will be made possible by the chardev interface, but is impossible to
achieve using sysfs by design.
Adding Linus to get his thou
ort for the GPIOs available
> on the Technologic Sytems board FPGA. It allows to set
> direction and read/write states.
>
> It uses the generic gpio driver.
No fancy stuff here, looks good to me but let's see what Linus says as
I am not too familiar with the generic GPIO driver.
Reviewed-by: Alexandre Courbot
spin_lock_init(&chips[i].lock);
>
> regs = gpio2regs(base);
> + if (!regs)
> + return -ENXIO;
Ok, a bit futile maybe but this *may* happen in theory...
Reviewed-by: Alexandre Courbot
On Wed, Feb 3, 2016 at 9:10 AM, nick wrote:
>
>
> On 2016-02-02 06:30 PM, Alexandre Courbot wrote:
>> On Fri, Jan 29, 2016 at 6:04 AM, Nicholas Krause wrote:
>>> This fixes a possible NULL pointer deference in the function,
>>> davinci_gpio_probe due to the func
ns(-)
Did a quick review and this looks all good, modulo the compile warning
on patch 6.
Reviewed-by: Alexandre Courbot
sm/gpio.h files for the arches that do not select
> ARCH_HAVE_CUSTOM_GPIO_H.
>
> This is a follow-on to 7563bbf89d06 ("gpiolib/arches: Centralise
> bolierplate asm/gpio.h").
Very nice.
Acked-by: Alexandre Courbot
501 - 600 of 1653 matches
Mail list logo
