On Thu, Dec 03, 2020 at 09:10:14AM +0200, Zulkifli, Muhammad Husaini wrote:
> >From: Linus Walleij
> >Sent: Thursday, December 3, 2020 2:55 AM
> >On Wed, Dec 2, 2020 at 8:04 AM
> >wrote:
...
> >If it should use any abstraction it should be a selector regulator IMO and
> >while that may seem ove
On Wed, Dec 02, 2020 at 11:53:42AM +0100, Ulf Hansson wrote:
> On Wed, 2 Dec 2020 at 08:02, wrote:
...
> > Kindly help to review this patch set.
>
> This version looks a lot better to me, but I am still requesting you
> to model the pinctrl correctly. I don't see a reason not to, but I may
> ha
On Mon, Jul 27, 2020 at 01:46:12PM +0200, Rafael J. Wysocki wrote:
> On Thu, Jul 16, 2020 at 7:38 PM Sumeet Pawnikar
> wrote:
> >
> > Modern Intel Mobile platforms support power limit4 (PL4), which is
> > the SoC package level maximum power limit (in Watts). It can be used
> > to preemptively limi
On Mon, Jun 08, 2020 at 01:37:25PM +0300, Wan Mohamad, Wan Ahmad Zainie wrote:
> > -Original Message-
> > From: Shevchenko, Andriy
> > On Mon, Jun 08, 2020 at 04:15:01PM +0800, Wan Ahmad Zainie wrote:
...
> > > +return PTR_ERR(priv->emmcclk);
&g
On Thu, Sep 26, 2019 at 07:51:00PM +0300, Schmauss, Erik wrote:
> > -Original Message-
> > From: linux-acpi-ow...@vger.kernel.org
> > On Behalf Of Shevchenko, Andriy
> > Sent: Thursday, September 26, 2019 9:35 AM
> > To: Schmauss, Erik
> > C
On Thu, Sep 26, 2019 at 07:09:05PM +0300, Schmauss, Erik wrote:
> > -Original Message-
> > From: Nikolaus Voss
> > Sent: Thursday, September 12, 2019 1:08 AM
> > To: Shevchenko, Andriy ; Schmauss, Erik
> > ; Rafael J. Wysocki ; Moore,
> > Robert
On Wed, Sep 25, 2019 at 09:13:34PM +0300, Schmauss, Erik wrote:
> > -Original Message-
> > From: Ferry Toth
> > Sent: Thursday, September 12, 2019 12:37 PM
> > To: Moore, Robert ; Nikolaus Voss
> > ; Shevchenko, Andriy
> > ; Schmauss, Erik ;
>
On Wed, Sep 25, 2019 at 12:18:11PM +0200, Nikolaus Voss wrote:
> On Tue, 24 Sep 2019, Moore, Robert wrote:
> > How about this:
> > Go back to using acpi_tb_install_and_load_table(), but then call
> > acpi_ns_initialize_objects afterwards This is what acpi_load_table does.
> >
> >
> >ACPI_INF
On Tue, Sep 24, 2019 at 03:07:34PM +0300, Shevchenko, Andriy wrote:
> On Mon, Sep 23, 2019 at 11:47:01AM +0200, Nikolaus Voss wrote:
> > For unloading an ACPI table, it is necessary to provide the
> > index of the table. The method intended for dynamically
> > loading or hotpl
On Mon, Sep 23, 2019 at 11:47:01AM +0200, Nikolaus Voss wrote:
> For unloading an ACPI table, it is necessary to provide the
> index of the table. The method intended for dynamically
> loading or hotplug addition of tables, acpi_load_table(),
> does not provide this information, so a new function
>
On Fri, Sep 13, 2019 at 05:20:21PM +0300, Moore, Robert wrote:
> -Original Message-
> From: Nikolaus Voss [mailto:n...@vosn.de]
> Sent: Friday, September 13, 2019 12:44 AM
> To: Moore, Robert
> Cc: Shevchenko, Andriy ; Schmauss, Erik
> ; Rafael J. Wysocki ; Le
On Tue, Aug 20, 2019 at 03:48:05PM +0300, Luck, Tony wrote:
>
> >> +#define INTEL_FAM6_ATOM_AIRMONT_NP0x75 /* Lightning Mountain */
> >
> > What's _NP ?
>
> Network Processor. But that is too narrow a descriptor. This is going to be
> used in
> other areas besides networking.
>
> I’m cont
Hi!
Recently I have experienced some nasty issue
genirq: Flags mismatch irq 18. 2000 (intel_mrfld_pwrbtn) vs.
2000 (bcove_irq_chip_pwrbtn)
but it is not a merit of my message here.
While trying to understand the logic behind real code and what is wished
(based on a comment) I have got d
Hi!
Experimenting with AtomISP (yes, code is ugly and MSI handling rather
hackish, though...).
So, with v4.14 base:
[ 33.639224] atomisp-isp2 :00:03.0: Start stream on pad 1 for asd0
[ 33.652355] atomisp-isp2 :00:03.0: irq:0x20
[ 33.662456] atomisp-isp2 :00:03.0: irq:0x20
[ 3
On Sat, 2017-11-18 at 18:53 +0200, Andy Shevchenko wrote:
> On Fri, 2017-11-17 at 18:01 -0600, Pierre-Louis Bossart wrote:
> > PCI/ACPI selections should not happen in Kconfig for machine
> > drivers,
> > move to SOC selections.
> >
> > Add distinction between PCI and ACPI HiFi2 platforms.
>
>
>
On Mon, 2017-04-03 at 17:31 +0300, Andy Shevchenko wrote:
> On Mon, 2017-04-03 at 16:27 +0200, Philipp Zabel wrote:
> >
> > > int rstc_id;
> > > int ret;
> > >
> > > - if (!node)
> > > - return ERR_PTR(-EINVAL);
> > > -
> >
> > This should be
> >
> > if (!node)
> >
On Mon, 2016-02-22 at 17:40 +0200, Andy Shevchenko wrote:
> On Mon, 2016-02-22 at 16:50 +0200, Heikki Krogerus wrote:
> > In device_remove_property_set(), if the primary fwnode is
> > of type "pset", it has to be set pointing to NULL before
> > calling set_secondary_fwnode(). Otherwise
> > set_seco
On Mon, 2015-12-21 at 21:34 +0200, Andy Shevchenko wrote:
> On Mon, 2015-12-21 at 19:10 +, Mans Rullgard wrote:
> > The datasheet requires that the LLP_[SD]_EN bits be cleared
> > whenever
> > LLP.LOC is zero, i.e. in the last descriptor of a multi-block
> > chain.
> > Make the driver do this.
On Fri, 2015-12-18 at 14:32 +0200, Andy Shevchenko wrote:
> On Fri, 2015-12-18 at 12:22 +0100, Anton Wuerfel wrote:
>
>
> > This comes with a slight change in behaviour as
> > pr_debug is configurable via CONFIG_DYNAMIC_DEBUG, whereas
> > printk(KERN_DEBUG ...) is not.
>
> --- a/drivers/tty/ser
Get 100% reproducible result on 4.4-rc3 on Intel BayTrail platform
Any suggestions?
P.S. Something like that was on 4.1-rc7 (same kernel config), though
didn't gather the traceback.
[0.00] Command line: vmlinuz.efi initrd=initrd
console=ttyS0,115200n8
[3.680557] clocksource: tsc: m
On Fri, 2015-11-27 at 11:56 +0200, Andy Shevchenko wrote:
> > > > >
> On Fri, 2015-11-27 at 00:15 +0100, Rafael J. Wysocki wrote:
> > On Thursday, November 26, 2015 06:45:17 PM Andy Shevchenko wrote:
> > > On Thu, 2015-11-26 at 18:30 +0200, Jarkko Nikula wrote:
> > > > On 11/26/2015 05:19 PM, Andy
On Thu, 2015-11-26 at 19:58 +0200, Andy Shevchenko wrote:
> On Thu, 2015-11-26 at 23:11 +0530, Vinod Koul wrote:
> > On Thu, Nov 26, 2015 at 07:24:48PM +0200, Andy Shevchenko wrote:
> > > On Thu, 2015-11-26 at 22:31 +0530, Vinod Koul wrote:
> > > > On Thu, Nov 26, 2015 at 05:19:11PM +0200, Andy She
On Thu, 2015-09-24 at 11:16 +0300, Andy Shevchenko wrote:
> On Thu, 2015-09-24 at 10:08 +0200, Martin Kletzander wrote:
> > Move all pointer-formatting documentation to one place in the code
> > and
> > one place in the documentation instead of keeping it in three
> > places
> > with different le
On Wed, 2015-08-05 at 17:02 +0300, Andy Shevchenko wrote:
> On Wed, 2015-08-05 at 16:39 +0300, Heikki Krogerus wrote:
[]
> > +#define PROP_ENTRY_STRING(_name_, _val_) { \
>
> …_STRING_ARRAY I can notice.
s / can / can't /
>
> > + .name = _name_, \
> > + .type = DEV_PROP_STRING, \
> > +
On Thu, 2015-06-04 at 11:21 +0200, Borislav Petkov wrote:
> Ok, here's an actual patch. I'm very sorry for the confusion and big
> thanks guys for catching it on time, before it hits the merge window!
>
> Much appreciated. :-D
Tested-by: Andy Shevchenko
Thanks!
> ---
> From: Borislav Petkov
>
On Wed, 2015-06-03 at 18:27 +0300, Andy Shevchenko wrote:
> > > I have a totally empty screen (serial console). So, if you teach me
> > > how to gather that I could do it later on.
> >
> > That'll be hard - you'd probably need a hardware debugger or something
> > special to get a RIP or other data
On Tue, 2015-05-26 at 15:28 +0100, Alan Cox wrote:
> > > +
> > > +#define UNIPHIER_UART_CHAR_FCR 3 /* Character / FIFO Control
> > > Register */
> > > +#define UNIPHIER_UART_LCR_MCR4 /* Line/Modem Control Register
> > > */
> > > +#define UNIPHIER_UART_LCR_SHIFT8
> >
>
On Mon, 2015-05-25 at 12:44 +0900, Masahiro Yamada wrote:
> Add the driver for on-chip UART used on UniPhier SoCs.
>
> This hardware is similar to 8250, but the register mapping is
> slightly different:
> - The offset to FCR, MCR is different.
> - The divisor latch access bit does not exist.
On Mon, 2015-02-23 at 14:45 +0200, Andy Shevchenko wrote:
> On Tue, 2015-01-20 at 23:49 +0200, Andy Shevchenko wrote:
> > This is the reworked patch series which had been sent earlier [1] to support
> > Intel CherryTrail SoC.
> >
> > The patches were tested on both BayTrail and CherryTrail SoCs.
>
On Tue, 2015-01-20 at 15:54 +, Lee Jones wrote:
> On Tue, 20 Jan 2015, Shevchenko, Andriy wrote:
>
> > On Tue, 2015-01-20 at 12:47 +, Lee Jones wrote:
> > > On Thu, 11 Dec 2014, Raymond Tan wrote:
> >
> > []
> >
> > > > +stati
On Tue, 2015-01-20 at 12:47 +, Lee Jones wrote:
> On Thu, 11 Dec 2014, Raymond Tan wrote:
[]
> > +static const struct i2c_mode_info platform_i2c_mode_info[] = {
> > + {
> > + .name = "Galileo",
> > + .i2c_scl_freq = 10,
> > + },
> > + {
> > + .name = "G
On Thu, 2014-12-11 at 17:38 +0800, Raymond Tan wrote:
> In Quark X1000, there's a single PCI device that provides both
> an I2C controller and a GPIO controller. This MFD driver will
> split the 2 devices for their respective drivers.
>
> This patch is based on Josef Ahmad's initial work for Quark
On Mon, 2014-11-03 at 09:43 +, Bryan O'Donoghue wrote:
> On 03/11/14 07:39, Raymond Tan wrote:
> > In Quark X1000, there's a single PCI device that provides both
> > an I2C controller and a GPIO controller. This MFD driver will
> > split the 2 devices for their respective drivers.
> >
> > This
On Tue, 2014-09-16 at 02:22 -0700, Weike Chen wrote:
> This patch enables suspend and resume mode for the power management, and
> it is based on Josef Ahmad's previous work.
>
Few comments below.
> Reviewed-by: Hock Leong Kweh
You still keep that guy as reviewer in a whole series, however I di
On Wed, 2014-09-10 at 14:11 -0500, atull wrote:
[]
> > static int dwapb_gpio_probe(struct platform_device *pdev)
> > {
> > + int i;
> > struct resource *res;
> > struct dwapb_gpio *gpio;
> > - struct device_node *np;
> > int err;
> > - unsigned int offs = 0;
> > + struct dev
On Thu, 2014-09-11 at 12:12 +0530, Vinod Koul wrote:
> On Tue, Aug 19, 2014 at 08:29:11PM +0300, Andy Shevchenko wrote:
> > The patchset is targeting two things:
> > - removal of slave_id which is deprecated (suggested by Arnd Bergmann)
> > - support BayTrail and Braswell SoCs in PCI case
> >
>
On Tue, 2014-09-09 at 01:50 +, Chen, Alvin wrote:
> > On Friday 05 September 2014 12:02:01 Shevchenko, Andriy wrote:
> > > > irq = irq_of_parse_and_map(node, 0); If (!irq) {
> > > > pp->irq = -1;
> > > > return;
> > > > } else {
>
On Fri, 2014-09-05 at 10:20 +, Chen, Alvin wrote:
> > > - port->bgc.gc.ngpio = ngpio;
> > > - port->bgc.gc.of_node = port_np;
> > > +#ifdef CONFIG_OF_GPIO
> >
> > Do we really need this #ifdef ?
> > of_node will be NULL anyway, or I missed something?
> Yes, otherwise, can't compile it. Please
On Fri, 2014-09-05 at 09:35 +, Chen, Alvin wrote:
> > Subject: Re: [PATCH 2/3 v2] GPIO: gpio-dwapb: Support Debounce
> >
> > On Fri, 2014-09-05 at 07:53 -0700, Weike Chen wrote:
> > > This patch enables 'debounce' for the designware GPIO, and it is based
> > > on Josef Ahmad's previous work.
>
On Fri, 2014-09-05 at 07:53 -0700, Weike Chen wrote:
> This patch enables suspend and resume mode for the power management, and
> it is based on Josef Ahmad's previous work.
>
> Reviewed-by: Hock Leong Kweh
> Reviewed-by: Shevchenko, Andriy
I have to recall my reviwed-b
eong Kweh
> Reviewed-by: Shevchenko, Andriy
> Signed-off-by: Weike Chen
> ---
> drivers/gpio/gpio-dwapb.c | 62
> +
> 1 file changed, 52 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/g
t; to enable the current Synopsys DesignWare APB GPIO driver to support the
> Multifunction device which exports the designware GPIO controller.
Few comments below.
>
> Reviewed-by: Hock Leong Kweh
> Reviewed-by: Shevchenko, Andriy
> Signed-off-by: Weike Chen
&g
On Thu, 2014-09-04 at 10:38 +, Chen, Alvin wrote:
>
> > > Since we enable this module not only support OF devices, but also support
> > MFD devices, so we remove OF_GPIO dependenc
> > > For 'PCI', the original code is also not depended on PCI, and this patch
> > > also
> > not, do you think i
On Thu, 2014-08-28 at 10:11 -0500, atull wrote:
> On Wed, 27 Aug 2014, Weike Chen wrote:
[]
> > +static inline u32 dwapb_read(struct dwapb_gpio *gpio, unsigned int offset)
> > +{
> > + struct bgpio_chip *bgc = &gpio->ports[0].bgc;
> > + void __iomem *reg_base = gpio->regs;
> > +
> > + ret
On Mon, 2014-07-28 at 14:06 +0300, Andy Shevchenko wrote:
> On Fri, 2014-07-25 at 17:55 +0200, Arnd Bergmann wrote:
> > On Friday 25 July 2014 13:45:47 Andy Shevchenko wrote:
[]
> > > > What I think you got wrong here (by following my bad advice) is the
> > > > master
> > > > number. Looking at
On Tue, 2014-05-20 at 09:40 -0300, Emilio López wrote:
> El 24/04/14 11:22, Maxime Ripard escribió:
> > The Allwinner A31 has a 16 channels DMA controller that it shares with the
> > newer A23. Although sharing some similarities with the DMA controller of the
> > older Allwinner SoCs, it's signific
On Thu, 2014-05-08 at 16:56 +0200, Arnd Bergmann wrote:
> The sa11x0_dma_pm_ops unconditionally reference sa11x0_dma_resume
> and sa11x0_dma_suspend, which currently breaks if CONFIG_PM_SLEEP
> is disabled.
>
> There is probably a better way to remove the reference in this
> case, but the safe cho
On Sun, 2014-05-04 at 18:22 +0800, Hongbo Zhang wrote:
> On 05/03/2014 12:46 AM, Vinod Koul wrote:
> > On Fri, Apr 18, 2014 at 04:17:51PM +0800, hongbo.zh...@freescale.com wrote:
> >> From: Hongbo Zhang
> >>
> >> This patch adds suspend resume functions for Freescale DMA driver.
> >> .prepare call
Hei!
During weekend the linux-next was being broken by introducing a lockdep
warning in the console code
[0.00] BIOS-e820: [mem 0xe000-0x]
reserved
[0.00]
[0.00] =
[0.00] [ INFO: possible recur
On Fri, 2014-04-18 at 17:41 +0800, Robin Gong wrote:
> On Thu, Apr 17, 2014 at 10:24:50AM +0000, Shevchenko, Andriy wrote:
> > On Thu, 2014-04-17 at 18:01 +0800, Robin Gong wrote:
[]
> > > + dev_dbg(sdma->dev, "memcpy: %x->%x, len=%d, channel=%d.\n",
>
On Thu, 2014-04-17 at 18:01 +0800, Robin Gong wrote:
> add "device_prep_dma_memcpy" and "device_prep_dma_sg" for memory copy by sdma.
>
> Signed-off-by: Robin Gong
> ---
> drivers/dma/imx-sdma.c | 188 +--
> 1 files changed, 164 insertions(+), 24 dele
On Thu, 2014-03-13 at 11:18 +0200, Peter Ujfalusi wrote:
> In case of not supported direction it is better to print the direction also.
> It is unlikely, but in such an event it helps with the debugging.
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/dma/edma.c | 4 ++--
> 1 file changed, 2 i
On Thu, 2014-03-13 at 11:18 +0200, Peter Ujfalusi wrote:
> Do not print the paRAM information when verbose debugging is not asked and
> also reduce the number of lines printed in edma_prep_dma_cyclic()
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/dma/edma.c | 11 +--
> 1 file change
On Tue, 2014-03-11 at 11:08 +0100, Maxime Ripard wrote:
[]
> > > + spin_lock_irq(&sdev->lock);
> > > + for (pchan_idx = 0; pchan_idx < NR_MAX_CHANNELS; pchan_idx++) {
> > > + pchan = &sdev->pchans[pchan_idx];
> > > +
> > > + if (pchan->vchan == NULL && !list_empty(&sdev->pending))
On Mon, 2014-03-10 at 15:41 +0100, Maxime Ripard wrote:
> The Allwinner A31 has a 16 channels DMA controller that it shares with the
> newer A23. Although sharing some similarities with the DMA controller of the
> older Allwinner SoCs, it's significantly different, I don't expect it to be
> possibl
On Sun, 2014-03-09 at 19:25 -0700, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> Add support Audio DMAC peri peri driver
> for Renesas R-Car Gen2 SoC, using 'shdma-base'
> DMA driver framework.
>
> Signed-off-by: Kuninori Morimoto
> ---
> v2 -> v3
My previous mail is applicable to thi
On Sun, 2014-03-09 at 18:34 -0700, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> Add support Audio DMAC peri peri driver
> for Renesas R-Car Gen2 SoC, using 'shdma-base'
> DMA driver framework.
Few comments below.
>
> Signed-off-by: Kuninori Morimoto
> ---
> resent
>
> - add missin
On Tue, 2014-03-04 at 17:18 +0100, Maxime Ripard wrote:
> The Allwinner A31 has a 16 channels DMA controller that it shares with the
> newer A23. Although sharing some similarities with the DMA controller of the
> older Allwinner SoCs, it's significantly different, I don't expect it to be
> possibl
On Mon, 2014-03-03 at 00:30 -0600, Andy Gross wrote:
> Add the DMA engine driver for the QCOM Bus Access Manager (BAM) DMA controller
> found in the MSM 8x74 platforms.
>
> Each BAM DMA device is associated with a specific on-chip peripheral. Each
> channel provides a uni-directional data transfe
On Fri, 2014-02-28 at 17:56 -0500, Santosh Shilimkar wrote:
> From: Sandeep Nair
>
> The Packet DMA driver sets up the dma channels and flows for the
> QMSS(Queue Manager SubSystem) who triggers the actual data movements
> across clients using destination queues. Every client modules like
> NETCP
On Fri, 2014-02-28 at 17:37 +0100, Maxime Ripard wrote:
> The Allwinner A31 has a 16 channels DMA controller that it shares with the
> newer A23. Although sharing some similarities with the DMA controller of the
> older Allwinner SoCs, it's significantly different, I don't expect it to be
> possibl
On Thu, 2014-02-27 at 10:44 +0530, George Cherian wrote:
> Start the channel tear down only if the channel is busy, else just
> bail out. In some cases its seen that by the time the tear down is
> initiated the cppi completes the DMA, especially in ISOCH transfers.
>
> Signed-off-by: George Cheria
On Thu, 2014-01-23 at 12:25 +0100, Lars-Peter Clausen wrote:
> On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
[...]
> > + /* Request the interrupt */
> > + chan->irq = irq_of_parse_and_map(node, 0);
> > + err = devm_request_irq(xdev->dev, chan->irq, xilinx_vdma_irq_handler,
> > +
On Mon, 2014-01-20 at 17:37 +0530, Vinod Koul wrote:
> On Mon, Jan 20, 2014 at 06:17:56PM +0530, Shevchenko, Andriy wrote:
> > On Mon, 2014-01-20 at 14:55 +0530, Vinod Koul wrote:
> > > On Thu, Dec 19, 2013 at 12:51:29PM +0200, Andy Shevchenko wrote:
> > > > On
On Mon, 2014-01-20 at 14:55 +0530, Vinod Koul wrote:
> On Thu, Dec 19, 2013 at 12:51:29PM +0200, Andy Shevchenko wrote:
> > On Wed, 2013-12-18 at 21:19 +0530, Vinod Koul wrote:
> > > On Mon, Dec 16, 2013 at 01:51:47PM +0530, Chew, Chiau Ee wrote:
> >
> > > > As mentioned by Andy, we are using *_no
On Tue, 2013-12-10 at 15:40 +0530, Vinod Koul wrote:
> On Tue, Dec 10, 2013 at 10:06:13PM +0800, Chew Chiau Ee wrote:
> > From: Chew, Chiau Ee
> >
> > This is to disable/enable DW_DMAC hw during suspend/resume.
> >
> > Signed-off-by: Chew, Chiau Ee
> > Acked-by: Andy Shevchenko
> > ---
> > dr
On Tue, 2013-12-03 at 08:05 +0900, Jingoo Han wrote:
> Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro
> is not preferred.
I'm sorry, but Documentation/PCI/pci.txt still says "is the preferred
method".
Is there any link to patch for Documentation and discussion why change
is establish
On Mon, 2013-12-02 at 11:06 +0200, Andy Shevchenko wrote:
> > Anyway, if you think you're going to do a lot of
> > transforms of printk("%x", dma_addr_t) with or without
> > (unsigned long long) or (u64) casts, I'll submit a signed
> > patch to Andrew.
>
> I think it worse to submit even if we h
On Fri, 2013-11-29 at 11:50 +, Will Deacon wrote:
> I see the following splat with 3.13-rc1 when attempting to perform DMA:
>
> [ 253.004516] Alignment trap: not handling instruction e1902f9f at
> []
> [ 253.004583] Unhandled fault: alignment exception (0x221) at 0xdfdfdfd7
> [ 253.004646]
On Mon, 2013-11-18 at 12:28 +0100, Florian Meier wrote:
> This driver adds support for digital audio (I2S)
> for the BCM2835 SoC that is used by the
> Raspberry Pi. External audio codecs can be
> connected to the Raspberry Pi via P5 header.
>
> It relies on cyclic DMA engine support for BCM2835.
On Sun, 2013-11-17 at 16:39 +0100, Florian Meier wrote:
> Add support for DMA controller of BCM2835 as used in the Raspberry Pi.
> Currently it only supports cyclic DMA.
Few comments below.
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -0,0 +1,736 @@
> +static int bcm2835_dma_abort(void __iomem *chan_b
On Fri, 2013-11-15 at 17:28 +0100, Florian Meier wrote:
> Add support for DMA controller of BCM2835 as used in the Raspberry Pi.
> Currently it only supports cyclic DMA.
Few comments below.
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -0,0 +1,749 @@
> +/*
> + * BCM2835 DMA engine support
> + *
> + * Th
On Wed, 2013-10-16 at 13:27 +0530, Vinod Koul wrote:
> On Wed, Oct 16, 2013 at 02:06:30PM +0530, Shevchenko, Andriy wrote:
> > On Wed, 2013-10-16 at 11:08 +0530, Vinod Koul wrote:
[]
> > > Well am going to take it a bit further and ask you why do we need the
> > > /
On Wed, 2013-10-16 at 11:08 +0530, Vinod Koul wrote:
> On Tue, Oct 15, 2013 at 08:55:20AM -0700, Dan Williams wrote:
> > On Tue, Oct 15, 2013 at 11:31 AM, Youquan Song
> > wrote:
> > > On Sun, Oct 13, 2013 at 08:56:33PM +0530, Vinod Koul wrote:
> > >> On Fri, Oct 11, 2013 at 06:33:43AM -0700, Greg
On Fri, 2013-10-11 at 17:42 -0400, Youquan Song wrote:
> Currently, the DMA channel calculates its data transferred only at network
> device driver. When other devices like UART or SPI etc, transfers data by DMA
> mode, but it always shows 0 at /sys/class/dma/dma0chan*/bytes_transferred.
>
> This
Hello, James.
Could you please share what is the License applied to the
lib/string_helpers.c module which you wrote on 2008?
Shall we update top of the file to be clear on it in future?
--
Andy Shevchenko
Intel Finland Oy
-
In
Hello!
It seems the one (as I think good) question was left unanswered:
http://www.spinics.net/lists/arm-kernel/msg186120.html
What is your opinions, comments?
--
Andy Shevchenko
Intel Finland Oy
-
Intel Finland Oy
Registered
On Mon, 2013-03-11 at 13:26 +0100, Guennadi Liakhovetski wrote:
> > Currently in linux-next we have the following things:
> >
> > $ git grep -n 'chan->device->dev->driver' drivers/dma/
> >
> > drivers/dma/amba-pl08x.c:1594: if (chan->device->dev->driver !=
> > &pl08x_amba_driver.drv)
> > driver
Hello.
Currently in linux-next we have the following things:
$ git grep -n 'chan->device->dev->driver' drivers/dma/
drivers/dma/amba-pl08x.c:1594: if (chan->device->dev->driver !=
&pl08x_amba_driver.drv)
drivers/dma/dmaengine.c:190:return chan->device->dev->driver->owner;
drivers/dma/edma.c
On Wed, 2013-01-30 at 10:07 +0200, Andy Shevchenko wrote:
> On Wed, 2013-01-30 at 13:31 +0530, Viresh Kumar wrote:
> > On Wed, Jan 30, 2013 at 1:02 PM, Andy Shevchenko
> > wrote:
> > > We get a device from the ACPI CSRT table. During enumeration we don't
> > > know what kind of the device it is.
On Tue, 2012-11-20 at 10:15 +0530, Viresh Kumar wrote:
> This adds following helper routines:
> - of_property_read_u8_array()
> - of_property_read_u16_array()
> - of_property_read_u8()
> - of_property_read_u16()
>
> This expects arrays from DT to be passed as:
> - u8 array:
> property = /bi
On Fri, 2012-10-12 at 23:31 +0530, Viresh Kumar wrote:
> This adds following helper routines:
> - of_property_read_u8_array()
> - of_property_read_u16_array()
> - of_property_read_u8()
> - of_property_read_u16()
>
> First two actually share most of the code with of_property_read_u32_array(),
> s
On Fri, 2012-10-12 at 19:36 +0530, Viresh Kumar wrote:
> On 12 October 2012 18:58, Shevchenko, Andriy
> wrote:
> > On Fri, 2012-10-12 at 11:14 +0530, Viresh Kumar wrote:
>
> >> + if (!of_property_read_u32(np, "nr_masters", &val)) {
> >> +
On Fri, 2012-10-12 at 11:14 +0530, Viresh Kumar wrote:
> dw_dmac driver already supports device tree but it used to have its platform
> data passed the non-DT way.
Another portion of comments.
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> +static struct dw_dma_platform_data *
>
84 matches
Mail list logo
