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
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
>
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
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.
> >
> >
> >
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
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
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
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
[
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
[
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 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, 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
> >
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
> >
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 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.
>
> ---
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.
>
> ---
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:
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:
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,
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,
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
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
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
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
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 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, \
+ .nval = 1,
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 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 andriy.shevche...@linux.intel.com
Thanks!
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
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 that
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 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
Indentation
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-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 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.
[1]
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 =
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 = GalileoGen2,
+
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:
[]
+static const struct i2c_mode_info platform_i2c_mode_info
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
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 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 patch is
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
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 hock.leong.k...@intel.com
You still keep that guy as reviewer in a
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
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 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
They are
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 device *dev =
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 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 {
pp-irq = irq;
}
Then the code looks strange.
How do you think
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-by
gt; 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/gpio/gpio-dwapb.
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
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 hock.leong.k...@intel.com
Reviewed-by: Shevchenko, Andriy andriy.shevche...@intel.com
Signed-off-by: Weike Chen
...@intel.com
Reviewed-by: Shevchenko, Andriy andriy.shevche...@intel.com
Signed-off-by: Weike Chen alvin.c...@intel.com
---
drivers/gpio/gpio-dwapb.c | 62
+
1 file changed, 52 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio
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 hock.leong.k...@intel.com
Reviewed-by: Shevchenko, Andriy andriy.shevche...@intel.com
I have
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.
Can we
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 refer 'struct
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
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 it is
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 = >ports[0].bgc;
> > + void __iomem *reg_base = gpio->regs;
> > +
> > + return
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;
+
+ return
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 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 the code for
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
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 significantly
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
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 choice
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
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 hongbo.zh...@freescale.com
This patch adds suspend resume functions for Freescale DMA driver.
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
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
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 Fri, 2014-04-18 at 17:41 +0800, Robin Gong wrote:
On Thu, Apr 17, 2014 at 10:24:50AM +, 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,
%pad for dma_addr_t variables.
Yes, %x here
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
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 b38...@freescale.com
---
drivers/dma/imx-sdma.c | 188 +--
1 files changed, 164
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
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
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 peter.ujfal...@ti.com
---
drivers/dma/edma.c | 11 +--
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 peter.ujfal...@ti.com
---
drivers/dma/edma.c | 4 ++--
1
On Tue, 2014-03-11 at 11:08 +0100, Maxime Ripard wrote:
[]
> > > + spin_lock_irq(>lock);
> > > + for (pchan_idx = 0; pchan_idx < NR_MAX_CHANNELS; pchan_idx++) {
> > > + pchan = >pchans[pchan_idx];
> > > +
> > > + if (pchan->vchan == NULL && !list_empty(>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
>
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
possible
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)) {
!pchan-vchan
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
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
1 - 100 of 156 matches
Mail list logo
