st a v3 later, hopefully after
dealing also with the answers to the doubts outlined above.
On 07/19/2016 06:49 PM, Thomas Gleixner wrote:
> On Tue, 19 Jul 2016, Sebastian Frias wrote:
>> +
>> +#define DBGERR(__format, ...) panic("[%s:%d]
Hi Jason,
On 07/06/2016 06:28 PM, Jason Cooper wrote:
> Hi Sebastian,
>
> On Wed, Jul 06, 2016 at 01:37:21PM +0200, Sebastian Frias wrote:
>> On 07/05/2016 06:16 PM, Jason Cooper wrote:
>>>> Come to think of it, I'm not sure the *name* of the file documenting
>
Hi Marc,
On 06/21/2016 12:18 PM, Marc Zyngier wrote:
>> Since irq-tango_v2.c is similar to irq-crossbar.c from TI (since it
>> is based on it), I was wondering what is the policy or recommendation
>> in such cases?
>> Should I attempt to merge the code (mainly the way to set up the
>> registers) o
Hi Marc,
On 06/21/2016 02:41 PM, Marc Zyngier wrote:
>> Ok, so after discussing with some HW engineers, they said that even
>> if this is a pure router and cannot latch by itself, since the
>> devices themselves latch their IRQ output, reading the 4x32bit RAW
>> status registers could work as well
se the
two previous ones to avoid code duplication.
Fixes: 16b2e6e2f31d ("irq_domain: Create common xlate functions that device
drivers can use")
Signed-off-by: Sebastian Frias
---
NOTE: the factored code is not strictly the same in the sense that
16b2e6e2f31d returns "intspec[1]&q
IS_ERR()
Fixes: 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
Signed-off-by: Sebastian Frias
---
drivers/gpio/gpio-dwapb.c | 2 +-
drivers/irqchip/irq-atmel-aic-common.c | 2 +-
kernel/irq/generic-chip.c | 24 ---
ed irq_map_generic_chip() function and also stated "This lacks a removal
function for now".
This commit provides with an implementation of an unmap function that can
be called by irq_domain_disassociate().
Fixes: 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
S
se the
two previous ones to avoid code duplication.
Fixes: 16b2e6e2f31d ("irq_domain: Create common xlate functions that device
drivers can use")
Signed-off-by: Sebastian Frias
---
NOTE: the factored code is not strictly the same in the sense that
16b2e6e2f31d returns "intspec[1]&q
Hi Mark,
On 09/12/2016 06:56 PM, Mark Rutland wrote:
>> Exactly, that's why to I'm having trouble to understand why there is so much
>> insistence on "getting the DT 100% right", since a HW change could imply
>> that what made 100% sense yesterday, does not today.
>> Since that is a possibility we
Hi Mark,
On 09/13/2016 03:12 PM, Mark Rutland wrote:
>> Exactly, that is why I was thinking it would take less "review" time.
>> Indeed, if there is no driver, why would it matter what those bindings
>> are?
>
> If you believe that the bindings don't matter, then there is absolutely
> no reason f
Hi Mark,
On 09/13/2016 03:12 PM, Mark Rutland wrote:
>> Exactly, that is why I was thinking it would take less "review" time.
>> Indeed, if there is no driver, why would it matter what those bindings
>> are?
>
> If you believe that the bindings don't matter, then there is absolutely
> no reason f
Hi Mark,
On 09/13/2016 05:47 PM, Mark Rutland wrote:
>>> If you believe that the bindings don't matter, then there is absolutely
>>> no reason for them to exist in the first place.
>>>
>>> If those binding matter to *anyone*, then those collating the bindings
>>> have some responsibility of stewar
Hi Mark,
On 09/13/2016 04:51 PM, Mark Rutland wrote:
> Hi,
>
> On Tue, Sep 13, 2016 at 04:22:09PM +0200, Sebastian Frias wrote:
>> On 09/13/2016 03:12 PM, Mark Rutland wrote:
>
> [context was deleted, TL;DR: binding review is necessary, and takes
> effort, regardless
Hi Thomas,
On 09/02/2016 05:12 PM, Thomas Gleixner wrote:
> On Mon, 1 Aug 2016, Sebastian Frias wrote:
>> NOTE: While the proposed unmap() function attempts to undo as much things
>> as done by the map() function, I did not find a way to undo the following:
>>
>> a) irq
Hi,
Given a SoC and its SDK, 3rd party users of said SoC (customers of the SoC's
manufacturer) may need/want to write kernel modules.
Since the DT describes the HW, it would make sense to expose some HW properties
through the DT, and have 3rd party users rely on them to write their drivers in
a ge
: Sebastian Frias
---
NOTE: I understand that the overcommit mode can be changed dynamically thru
sysctl, but on embedded systems, where we know in advance that overcommit
will be disabled, there's no reason to postpone such setting.
I would also be interested in knowing if you guys think
nges.
Signed-off-by: Sebastian Frias
---
NOTE: I understand that the overcommit mode can be changed dynamically thru
sysctl, but on embedded systems, where we know in advance that overcommit
will be disabled, there's no reason to postpone such setting.
I would also be interested in knowing if y
Hi Andy,
On 05/10/2016 02:39 PM, Andy Whitcroft wrote:
> On Tue, May 10, 2016 at 02:00:47PM +0200, Sebastian Frias wrote:
>> Hi,
>>
>> Using checkpatch.pl on the forwarded patch results in:
>>
>> WARNING: please write a paragraph that describes the config symbol f
checkpatch.pl currently warns if Kconfig options are properly
described by checking the length of the config description.
This patch is an attempt to make the message less cryptic.
Signed-off-by: Sebastian Frias
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Hi,
Some bootloaders (like U-boot) support several HW devices: serial, network,
NAND, USB, etc. most of which are also supported by Linux.
So the question is: is code shared? I mean, I understand that the drivers need
to talk to the appropriate API, and such API could be different between Linux
Hi Alan,
On 05/13/2016 05:41 PM, One Thousand Gnomes wrote:
>> My understanding is that there was a time when there was no overcommit at
>> all.
>> If that's the case, understanding why overcommit was introduced would be
>> helpful.
>
> Linux always had overcommit.
>
> The origin of overcommit
Hi Tom,
On 05/21/2016 03:41 AM, Tom Rini wrote:
> On Fri, May 20, 2016 at 04:28:23PM +0200, Sebastian Frias wrote:
>
>> Hi,
>>
>> Some bootloaders (like U-boot) support several HW devices: serial,
>> network, NAND, USB, etc. most of which are also supported by Linux
Hi Alan,
On 05/13/2016 05:43 PM, One Thousand Gnomes wrote:
>> But wouldn't those affect a given process at at time?
>> Does that means that the OOM-killer is woken up to kill process X when those
>> situations arise on process Y?
>
> Not sure I understand the question.
I'm sorry for the "at at
Hi Michal,
On 05/17/2016 10:57 AM, Michal Hocko wrote:
> On Tue 17-05-16 10:24:20, Sebastian Frias wrote:
> [...]
>>>> Also, under what conditions would copy-on-write fail?
>>>
>>> When you have no memory or swap pages free and you touch a COW page that
&g
Hi Austin,
On 05/17/2016 07:29 PM, Austin S. Hemmelgarn wrote:
>> I see the difference, your answer seems a bit like the one from Austin,
>> basically:
>> - killing a process is a sort of kernel protection attempting to deal
>> "automatically" with some situation, like deciding what is a 'memory
Hi Michal,
On 05/17/2016 10:16 PM, Michal Hocko wrote:
> On Tue 17-05-16 18:16:58, Sebastian Frias wrote:
> [...]
>> From reading Documentation/cgroup-v1/memory.txt (and from a few
>> replies here talking about cgroups), it looks like the OOM-killer is
>> still being
9325 ("net: phy: at803x: Add support for hardware reset")
Signed-off-by: Sebastian Frias
---
drivers/net/phy/at803x.c | 43 ---
1 file changed, 20 insertions(+), 23 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
in
Hi,
Sergei pointed out that the same patch was submitted yesterday by Timur (what
are the chances?! :-) ) https://patchwork.ozlabs.org/patch/615019/
Regards,
Sebastian
On 04/27/2016 01:34 PM, Sebastian Frias wrote:
> There is no need to register the callback introduced by
>
Hi,
On 05/13/2016 10:44 AM, Mason wrote:
> On 13/05/2016 10:04, Michal Hocko wrote:
>
>> On Tue 10-05-16 13:56:30, Sebastian Frias wrote:
>> [...]
>>> NOTE: I understand that the overcommit mode can be changed dynamically thru
>>> sysctl, but on embedded sy
Hi,
On 05/13/2016 12:18 PM, Mason wrote:
> On 13/05/2016 11:52, Michal Hocko wrote:
>> On Fri 13-05-16 10:44:30, Mason wrote:
>>> On 13/05/2016 10:04, Michal Hocko wrote:
>>>
>>>> On Tue 10-05-16 13:56:30, Sebastian Frias wrote:
>>>> [...]
>&
Hi Michal,
On 05/13/2016 02:00 PM, Michal Hocko wrote:
> On Fri 13-05-16 11:52:30, Sebastian Frias wrote:
>>
>> By the way, do you know what's the rationale to allow this setting to
>> be controlled by the userspace dynamically? Was it for testing only?
>
> Dunn
Hi Austin,
On 05/13/2016 03:11 PM, Austin S. Hemmelgarn wrote:
> On 2016-05-13 08:39, Sebastian Frias wrote:
>> Well, a more urgent problem would be that in that case overcommit=never is
>> not really well tested.
> I know more people who use overcommit=never than overcommit
Hi Austin,
On 05/13/2016 03:11 PM, Austin S. Hemmelgarn wrote:
> On 2016-05-13 08:39, Sebastian Frias wrote:
>>
>> My point is that it seems to be possible to deal with such conditions in a
>> more controlled way, ie: a way that is less random and less abrupt.
> There
Hi Michal,
On 05/13/2016 04:01 PM, Michal Hocko wrote:
> On Fri 13-05-16 14:15:35, Mason wrote:
>> On 13/05/2016 13:44, Michal Hocko wrote:
>>
>>> Anyway, this is my laptop where I do not run anything really special
>>> (xfce, browser, few consoles, git, mutt):
>>> $ grep Commit /proc/meminfo
>>>
Hi Austin,
On 05/13/2016 04:14 PM, Austin S. Hemmelgarn wrote:
> On 2016-05-13 09:34, Sebastian Frias wrote:
>> Hi Austin,
>>
>> On 05/13/2016 03:11 PM, Austin S. Hemmelgarn wrote:
>>> On 2016-05-13 08:39, Sebastian Frias wrote:
>>>>
>>>> My p
Hi Austin,
On 05/13/2016 03:51 PM, Austin S. Hemmelgarn wrote:
> On 2016-05-13 09:32, Sebastian Frias wrote:
>> I didn't see that in Documentation/vm/overcommit-accounting or am I looking
>> in the wrong place?
> It's controlled by a sysctl value, so it's listed
Hi Alan,
On 05/13/2016 05:01 PM, One Thousand Gnomes wrote:
> On Fri, 13 May 2016 15:34:52 +0200
> Sebastian Frias wrote:
>
>> Hi Austin,
>>
>> On 05/13/2016 03:11 PM, Austin S. Hemmelgarn wrote:
>>> On 2016-05-13 08:39, Sebastian Frias wrote:
>&
Hi Michal,
On 05/13/2016 04:51 PM, Michal Hocko wrote:
>
> The default should cover the most use cases. If you can prove that the
> vast majority of embeded systems are different and would _benefit_ from
> a different default I wouldn't be opposed to change the default there.
I'm unsure of a way
Hi Alan,
On 05/13/2016 05:11 PM, One Thousand Gnomes wrote:
>> It seems important to point out that Sebastian's patch does NOT change
>> the default behavior. It merely creates a knob allowing one to override
>> the default via Kconfig.
>>
>> +choice
>> +prompt "Overcommit Mode"
>> +defaul
Hi Alan,
On 05/13/2016 05:04 PM, One Thousand Gnomes wrote:
>>> Perhaps Sebastian's choice could be made to depend on CONFIG_EMBEDDED,
>>> rather than CONFIG_EXPERT?
>>
>> Even if the overcommit behavior is different on those systems the
>> primary question hasn't been answered yet. Why cannot t
---
resending as plain-text
---
drivers/tty/serial/8250/8250_core.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 2c46a21..9ca863c 100644
--- a/drivers/tty/serial/8250/8250
On 12/17/2015 05:29 PM, Peter Hurley wrote:
On 12/17/2015 07:15 AM, Sebastian Frias wrote:
---
I think there are a few minor bugs on the 8250 UART code.
Below you can find a patch with a proposed solution.
In a nutshell:
- probe_baud from 87515772c33ee8a0cc08d984a7d2401eeff074cd was
On 12/17/2015 05:02 PM, Måns Rullgård wrote:
Sebastian Frias writes:
---
resending as plain-text
---
drivers/tty/serial/8250/8250_core.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250
Hi Peter,
On 12/17/2015 06:48 PM, Peter Hurley wrote:
Hi Sebastian,
On 12/17/2015 08:48 AM, Sebastian Frias wrote:
On 12/17/2015 05:29 PM, Peter Hurley wrote:
On 12/17/2015 07:15 AM, Sebastian Frias wrote:
---
I think there are a few minor bugs on the 8250 UART code.
Below you can find a
On 12/17/2015 06:21 PM, Greg Kroah-Hartman wrote:
On Thu, Dec 17, 2015 at 05:48:42PM +0100, Sebastian Frias wrote:
On 12/17/2015 05:29 PM, Peter Hurley wrote:
On 12/17/2015 07:15 AM, Sebastian Frias wrote:
---
I think there are a few minor bugs on the 8250 UART code.
Below you can find a
---
Some UART HW has a single register combining UART_DLL/UART_DLM
(this was probably forgotten in the change that introduced the
callbacks, commit b32b19b8ffc05cbd3bf91c65e205f6a912ca15d9)
Fixes: b32b19b8ffc0
Signed-off-by: Sebastian Frias
---
drivers/tty/serial/8250/8250_port.c | 17
Hi Peter,
On 12/17/2015 09:09 PM, Peter Hurley wrote:
It's confusing though, given there are multiple ways to express the same thing.
I also found parts of the doc confusing in that regard as well.
ie: there's also a "stdout-path" DT key.
Yep. Thing is, once it goes into the command line and s
Hi,
We are porting a driver from Linux 3.4.39+ to 4.1.13+, CPU is Cortex-A9.
The driver maps kmalloc'ed memory to user space.
The usermode sees a contiguous space, although in reality it could span
several chunks of memory allocated with separate calls to kmalloc.
For simplicity, the below exam
On 12/09/2015 03:32 PM, Michal Hocko wrote:
On Wed 09-12-15 15:07:50, Marc Gonzalez wrote:
On 09/12/2015 14:55, Michal Hocko wrote:
On Tue 08-12-15 18:25:31, Sebastian Frias wrote:
Hi,
We are porting a driver from Linux 3.4.39+ to 4.1.13+, CPU is Cortex-A9.
The driver maps kmalloc'ed m
On 12/09/2015 04:12 PM, Michal Hocko wrote:
On Wed 09-12-15 15:53:22, Sebastian Frias wrote:
[...]
2) Now that VM_RESERVED was removed, is there another recommended flag to
replace it for the purposes above?
VM_IO + potentially others depending on your usecase.
3) Since it was working
patch adds support for the "fixed-link" node to the
nb8800 driver.
Signed-off-by: Sebastian Frias
---
drivers/net/ethernet/aurora/nb8800.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/aurora/nb8800.c
b/drivers/net/ethernet/au
On 02/05/2016 04:26 PM, Måns Rullgård wrote:
Sebastian Frias writes:
On 02/05/2016 04:08 PM, Måns Rullgård wrote:
Sebastian Frias writes:
On 02/05/2016 03:34 PM, Måns Rullgård wrote:
Sebastian Frias writes:
Signed-off-by: Sebastian Frias
Please change the subject to something like
On 02/08/2016 02:37 PM, Måns Rullgård wrote:
Sebastian Frias writes:
On 02/05/2016 04:26 PM, Måns Rullgård wrote:
Sebastian Frias writes:
On 02/05/2016 04:08 PM, Måns Rullgård wrote:
Sebastian Frias writes:
On 02/05/2016 03:34 PM, Måns Rullgård wrote:
Sebastian Frias writes
On 02/08/2016 03:11 PM, Mason wrote:
On 08/02/2016 14:37, Måns Rullgård wrote:
Sebastian Frias wrote:
By the way, I know some people like the command line, email, etc. but
there ought to be other tools better suited for patch review...
Some kernel subsystems use http://patchwork.ozlabs.org
Hi Uwe, Daniel,
On 03/18/2016 01:54 PM, Uwe Kleine-König wrote:
> [expand cc a bit more]
>
> Hello,
>
> On Wed, Mar 16, 2016 at 06:25:59PM +0100, Sebastian Frias wrote:
>> Commit 687908c2b649 ("net: phy: at803x: simplify using
>> devm_gpiod_get_optional and
LIB is not
selected.
Fixes: 687908c2b649 ("net: phy: at803x: simplify using
devm_gpiod_get_optional and its 4th argument")
Signed-off-by: Sebastian Frias
---
drivers/net/phy/at803x.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/at803x.c b/driv
Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with
continuous bitfields, just as BIT(x) does for single bits.
SETBITFIELD_ULL(msb, lsb, value) macro is also added.
Signed-off-by: Sebastian Frias
---
Code protected with "#ifdef __KERNEL__" just as the BIT(x)
macros.
I
On 05/12/16 16:34, Borislav Petkov wrote:
> On Mon, Dec 05, 2016 at 02:36:07PM +0100, Sebastian Frias wrote:
>> + * Equivalent of BIT(x) but for contiguous bitfields
>> + * SETBITFIELD(1, 0,0xff) = 0x0003
>> + * SETBITFIELD(3, 0,0xff) = 0x000f
>> + * SETBITFI
On 05/12/16 18:13, Linus Torvalds wrote:
> On Mon, Dec 5, 2016 at 5:36 AM, Sebastian Frias wrote:
>> Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with
>> continuous bitfields, just as BIT(x) does for single bits.
>>
>> SETBITFIELD_ULL(msb, lsb, value) m
|= GENVALUE(19, 12, 0x5a);
now 'val = 0x1115a000'
Signed-off-by: Sebastian Frias
---
Change in v2:
- rename the macro to GENVALUE as proposed by Linus
- longer comment attempts to show use case for the macro as
proposed by Borislav
---
include/linux/bitops.h | 14 ++
1 fi
|= GENVALUE(19, 12, 0x5a);
now 'val = 0x1115a000'
Signed-off-by: Sebastian Frias
Link: https://marc.info/?l=linux-kernel&m=148094498711000&w=2
---
Change in v2:
- rename the macro to GENVALUE as proposed by Linus
- longer comment attempts to show use case for the macro as
pr
On 05/12/16 18:48, Geert Uytterhoeven wrote:
> On Mon, Dec 5, 2016 at 2:36 PM, Sebastian Frias wrote:
>> Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with
>> continuous bitfields, just as BIT(x) does for single bits.
>
> If it's a bitfield, why not
On 05/12/16 19:23, Linus Torvalds wrote:
> On Mon, Dec 5, 2016 at 9:49 AM, Sebastian Frias wrote:
>> Introduce GENVALUE(msb, lsb, value) macro to ease dealing with
>> continuous bitfields, just as BIT(x) does for single bits.
>
> Oh, and looking at the implementation, this i
On 06/12/16 11:42, Geert Uytterhoeven wrote:
> On Tue, Dec 6, 2016 at 11:31 AM, Sebastian Frias wrote:
>> On 05/12/16 18:48, Geert Uytterhoeven wrote:
>>> On Mon, Dec 5, 2016 at 2:36 PM, Sebastian Frias wrote:
>>>> Introduce SETBITFIELD(msb, lsb, value) macro to eas
Hi,
On 05/12/16 17:30, Doug Anderson wrote:
>
> AKA: you are setting up various "corecfg" stuff that's documented in
> the generic Arasan docs. Others SDHCI-Arasan implementations might
> want to set the same things, but those values may be stored elsewhere
> for them.
Exactly, that is what I'
Hi Geert,
On 06/12/16 12:12, Geert Uytterhoeven wrote:
>>> ... which means "generate a value"??
>>>
>>
>> Yes.
>> Although I'm not sure if I understood the essence of your point.
>> Are you suggesting that the name should be GENERATE_A_VALUE?
>
> No. I mean that "value" is a way too generic name.
, 12);
=> 'b = 0xa5'
BITFIELD_INSERT(a, 19, 12, 0xff5a);
=> 'a = 0x1115a000'
Signed-off-by: Sebastian Frias
Link: https://marc.info/?l=linux-kernel&m=148094498711000&w=2
---
Change in v2:
- rename the macro to GENVALUE as proposed by Linus
- longer com
;
u32 b = BITFIELD_EXTRACT(a, 19, 12);
=> b = 0xa5;
BITFIELD_INSERT(a, 19, 12, 0xff5a);
=> a = 0x1115a000;
Signed-off-by: Sebastian Frias
Link: https://marc.info/?l=linux-kernel&m=148094498711000&w=2
---
Change in v2:
- rename the macro to GENVALUE as proposed by Linus
- longer comment a
On 07/12/16 09:42, Kalle Valo wrote:
> Sebastian Frias writes:
>
>> Introduce GENVALUE(msb, lsb, value) macro to ease dealing with
>> continuous bitfields, just as BIT(x) does for single bits.
>>
>> GENVALUE_ULL(msb, lsb, value) macro is also added.
>>
&
On 07/12/16 12:05, Jakub Kicinski wrote:
> On Wed, 7 Dec 2016 11:00:57 +0100, Sebastian Frias wrote:
>> On 07/12/16 09:42, Kalle Valo wrote:
>>> Sebastian Frias writes:
>>>
>>>> Introduce GENVALUE(msb, lsb, value) macro to ease dealing with
>>>
On 07/12/16 13:38, Jakub Kicinski wrote:
> On Wed, 7 Dec 2016 12:23:56 +0100, Sebastian Frias wrote:
>> On 07/12/16 12:05, Jakub Kicinski wrote:
>>> On Wed, 7 Dec 2016 11:00:57 +0100, Sebastian Frias wrote:
>>>> On 07/12/16 09:42, Kalle Valo wrote:
On 07/12/16 15:02, Jakub Kicinski wrote:
> On Wed, 7 Dec 2016 14:51:36 +0100, Sebastian Frias wrote:
>> On 07/12/16 13:38, Jakub Kicinski wrote:
>>> On Wed, 7 Dec 2016 12:23:56 +0100, Sebastian Frias wrote:
>>>> On 07/12/16 12:05, Jakub Kicinski wrote:
>>&
This adds support for a second-gen irq router/controller present
on some Sigma Designs chips.
Signed-off-by: Sebastian Frias
---
This is RFC v2 attempts to address the comments given on the previous
RFC:
- domains used to be created by the DT, now they are created internally
by the driver
Hi,
We are trying to write a driver for an interrupt controller (actually more of a
crossbar) for an ARM-based SoC.
This IRQ crossbar has 128 inputs and 24 outputs, the outputs are connected
directly to the GIC.
The idea is that the GIC handles everything, and just request a mapping from an
IRQ
Hi Marc,
On 07/05/2016 07:13 PM, Marc Zyngier wrote:
>>> You really don't need to describe this. The configuration that is
>>> applied to your router in entirely under software control,
>>
>> With "entirely under software control" do you mean this driver's code?
>
> Yes.
Ok.
>
>>
>>> and none
Hi,
On 07/06/2016 11:30 AM, Thomas Gleixner wrote:
> On Wed, 6 Jul 2016, Marc Zyngier wrote:
>> On 05/07/16 20:24, Thomas Gleixner wrote:
>>> On Tue, 5 Jul 2016, Marc Zyngier wrote:
Hardcoded? No way. You simply implement a route allocator in your
driver, assigning them as needed. And ye
Hi Jason,
On 07/05/2016 06:16 PM, Jason Cooper wrote:
>> Come to think of it, I'm not sure the *name* of the file documenting
>> a binding is as important to DT maintainers as the compatible string.
>
> Correct. devicetee compatible strings need to be as specific as
> possible.
Specific with
Hi Marc,
On 07/06/2016 03:50 PM, Marc Zyngier wrote:
>> I think that's where part the misunderstanding comes from.
>> IMHO the output line is not a direct function of the input line.
>> Any of the 64 IRQ lines entering the "old controller" (irq-tango.c) can be
>> routed to any of its 3 outputs.
>
Hi Marc,
On 06/13/2016 06:24 PM, Marc Zyngier wrote:
>> My understanding of "hierarchical irq domains" is that it is useful
>> when there are multiple stacked interrupt controllers. Also, the
>> documentation says "the majority of drivers should use the linear
>> map" (as opposed to the hierarchic
On 06/14/2016 06:37 PM, Sebastian Frias wrote:
>>>> Also, without seeing the code,
>>>> it is pretty difficult to make any meaningful comment...
>>>
>>> Base code is either 4.7rc1 or 4.4.
>>> The irq-crossbar code is not much different from TI, b
On 07/04/2016 02:11 PM, Mason wrote:
>
> In the patch subject, do you mean SMP as in Symmetric Multi Processor?
As in Sigma Multimedia Processor :-)
The prefix for Sigma's chips is SMP.
I can change that to "Tango" if it is confusing.
>
> Is that the address you intend to submit with?
Yes.
>
Hi Jason,
On 07/05/2016 04:41 PM, Jason Cooper wrote:
> Hey Sebastian, Mason,
>
> * Please fix mailer to wrap text at a sane length. I've re-wrapped and
> trimmed.
>
> On Tue, Jul 05, 2016 at 02:30:12PM +0200, Sebastian Frias wrote:
>> On 07/04/2016 02:11 PM, Mason
Hi Jason,
On 07/05/2016 05:53 PM, Jason Cooper wrote:
>>
>> Thanks for your comments.
>> So, aside from some naming issues, do you think the driver is ok?
>
> Well, it's going to be few days before I can really dig in to this.
> Until then, what I can say I see is that it looks like you're using
Hi Marc,
On 07/05/2016 06:48 PM, Marc Zyngier wrote:
>> I already did something like that, you can see it here:
>>
>> https://marc.info/?l=linux-kernel&m=146592235919308&w=2
>>
>> the problem with that code is that it cannot handle more than 24 IRQs (the
>> number of outputs of the router), becaus
On 11/04/2016 05:49 PM, Måns Rullgård wrote:
>>> But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers
>>> will apply the delay.
>>>
>>> I think a better way of dealing with this is that both, PHY and MAC
>>> drivers exchange information so that the delay is applied only once.
>>
>
Hi,
Documentation/networking/phy.txt discusses phy_connect and states that:
"...
interface is a u32 which specifies the connection type used
between the controller and the PHY. Examples are GMII, MII,
RGMII, and SGMII. For a full list, see include/linux/phy.h
Now just make sure that phyd
On 11/09/2016 06:07 PM, Florian Fainelli wrote:
> On 11/09/2016 05:24 AM, Sebastian Frias wrote:
>> Hi,
>>
>> Documentation/networking/phy.txt discusses phy_connect and states that:
>>
>> "...
>>
>> interface is a u32 which specifies the conne
On 11/09/2016 06:03 PM, Florian Fainelli wrote:
> On 11/09/2016 05:02 AM, Sebastian Frias wrote:
>> On 11/04/2016 05:49 PM, Måns Rullgård wrote:
>>>>> But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers
>>>>> will apply the delay.
>>&
Hi,
When using the Arasan SDHCI HW IP, there is a set of parameters called
"Hardware initialized registers"
(Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4
AHB Host Controller", revision 6.0 document)
In some platforms those signals are connected to registers that need
Hi Adrian,
On 28/11/16 11:30, Adrian Hunter wrote:
> On 28/11/16 09:32, Michal Simek wrote:
>> +Sai for Xilinx perspective.
>>
>> On 25.11.2016 16:24, Sebastian Frias wrote:
>>> Hi,
>>>
>>> When using the Arasan SDHCI HW IP, there is a set of param
On 28/11/16 12:44, Adrian Hunter wrote:
> On 28/11/16 13:20, Sebastian Frias wrote:
>> Hi Adrian,
>>
>> On 28/11/16 11:30, Adrian Hunter wrote:
>>> On 28/11/16 09:32, Michal Simek wrote:
>>>> +Sai for Xilinx perspective.
>>>>
>
On 28/11/16 14:28, Sebastian Frias wrote:
> On 28/11/16 12:44, Adrian Hunter wrote:
>> On 28/11/16 13:20, Sebastian Frias wrote:
>>> Hi Adrian,
>>>
>>> On 28/11/16 11:30, Adrian Hunter wrote:
>>>> On 28/11/16 09:32, Michal Simek wrote:
>>>
Hi Thomas,
On 10/24/2016 06:55 PM, Thomas Gleixner wrote:
> On Mon, 24 Oct 2016, Mason wrote:
>>
>> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
>> makes the system lock-up disappear.
>
> The way how lazy irq disabling works is:
>
> 1) Interrupt is marked disabled in softw
Hi Doug,
On 28/11/16 18:46, Doug Anderson wrote:
> Hi,
>
> On Mon, Nov 28, 2016 at 6:39 AM, Sebastian Frias wrote:
>>> I will try to send another patch with what a different approach
>>>
>>
>> Here's a different approach (I just tested that it b
Hi Doug,
On 28/11/16 19:02, Doug Anderson wrote:
> Hi,
>
> On Mon, Nov 28, 2016 at 5:28 AM, Sebastian Frias wrote:
>> +static void sdhci_tango4_platform_init(struct sdhci_host *host)
>> +{
>> + printk("%s\n", __func__);
>> +
>> +
On 09/12/16 07:59, Vinod Koul wrote:
> On Thu, Dec 08, 2016 at 04:48:18PM +, Måns Rullgård wrote:
>> Vinod Koul writes:
>>
>>> To make it efficient, disregarding your Sbox HW issue, the solution is
>>> virtual channels. You can delink physical channels and virtual channels. If
>>> one has SW c
Hi Marc,
On 06/14/2016 06:39 PM, Sebastian Frias wrote:
> On 06/14/2016 06:37 PM, Sebastian Frias wrote:
>>>>> Also, without seeing the code,
>>>>> it is pretty difficult to make any meaningful comment...
>>>>
>>>> Base code is eit
The delay can be applied at PHY or MAC level, but since
PHY drivers will apply the delay at PHY level when using
one of the "internal delay" declinations of RGMII mode
(like PHY_INTERFACE_MODE_RGMII_TXID), applying it again
at MAC level causes issues.
Signed-off-by: Sebastian Frias
--
E_MODE_RGMII_TXID to deal with internal delays.
Those are all RGMII modes (1Gbit) and must be considered that way when
setting the MAC Mode or the Pads Mode for the HW to work properly.
Signed-off-by: Sebastian Frias
---
drivers/net/ethernet/aurora/nb8800.c | 10 ++
1 file changed
Hi Andrew,
On 11/04/2016 04:11 PM, Andrew Lunn wrote:
> On Fri, Nov 04, 2016 at 04:02:24PM +0100, Sebastian Frias wrote:
>> The delay can be applied at PHY or MAC level, but since
>> PHY drivers will apply the delay at PHY level when using
>> one of the "internal delay&q
1 - 100 of 164 matches
Mail list logo
