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
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:
>>&
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 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 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.
>>
&
;
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
, 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
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.
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'
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
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 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
|= 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
|= 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
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
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
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
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__);
>> +
>> +
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
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:
>>>
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.
>>>>
>
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
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
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.
>>&
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
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/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 Måns,
On 11/05/2016 01:58 PM, Måns Rullgård wrote:
>> if (gigabit) {
>> -if (priv->phy_mode == PHY_INTERFACE_MODE_RGMII)
>> +if (phy_interface_is_rgmii(phydev))
>> mac_mode |= RGMII_MODE;
>>
>> mac_mode |= GMAC_MODE;
>
> As I said
Hi David,
On 11/04/2016 06:54 PM, David Miller wrote:
> From: Sebastian Frias
> Date: Fri, 4 Nov 2016 18:02:15 +0100
>
>> Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition")
>> and commit 7d400a4c5897 ("phylib: add PHY interface modes for
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 pad mode for the HW to work properly.
Signed-off-by: Sebastian Frias
---
drivers/net/ethernet/aurora/nb8800.c | 8
1 file changed, 4 insert
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
--
This is v3 of the series, it fixes formatting issues of v2.
In v2 of the series, only the second patch:
"net: ethernet: nb8800: handle all RGMII definitions" is modified
to account for Florian's suggestion.
Sebastian Frias (2):
net: ethernet: nb8800: Do not apply TX delay at
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 pad mode for the HW to work properly.
Signed-off-by: Sebastian Frias
---
drivers/net/ethernet/aurora/nb8800.c | 8
1 file changed, 4 insert
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
-
This is v2 of the series, only the second patch:
"net: ethernet: nb8800: handle all RGMII definitions" is modified
to account for Florian's suggestion.
Sebastian Frias (2):
net: ethernet: nb8800: Do not apply TX delay at MAC level
net: ethernet: nb8800: handle all RGMII defini
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 pad mode for the HW to work properly.
Signed-off-by: Sebastian Frias
---
drivers/net/ethernet/aurora/nb8800.c | 8
1 file changed, 4 insert
On 11/04/2016 05:23 PM, Florian Fainelli wrote:
>
>
> On 11/04/2016 08:05 AM, Sebastian Frias wrote:
>> Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition")
>> and commit 7d400a4c5897 ("phylib: add PHY interface modes for internal
>>
Hi Måns,
On 11/04/2016 04:18 PM, Måns Rullgård wrote:
> Sebastian Frias writes:
>
>> 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" d
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
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
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
--
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 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 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 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/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 Warner,
On 09/12/2016 04:26 PM, Warner Losh wrote:
> On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland wrote:
>>> Since the question seems understood, do you have an example of other SoC's
>>> doing something similar?
>>
>> I do not have an example. I know that others are using DT for data
>> beyo
On 09/12/2016 06:07 PM, Sebastian Frias wrote:
> Hi Mark,
>
> On 09/12/2016 04:01 PM, Mark Rutland wrote:
>>> 3rd parties could choose to write a driver (as opposed to use say, a
>>> user-mode
>>> library) if it fits their programming model better, if t
Hi Mark,
On 09/12/2016 04:01 PM, Mark Rutland wrote:
>> 3rd parties could choose to write a driver (as opposed to use say, a
>> user-mode
>> library) if it fits their programming model better, if they think they would
>> have better performance, or other reasons.
>
> A vendor can always choose t
Hi Mark,
On 09/12/2016 02:38 PM, Mark Rutland wrote:
>>
>> 3rd party users of said SoC could then write kernel modules for such HW
>> blocks using the DT description. The DT would thus become the authoritative
>> source of information regarding register programming for the SoC.
>
> I don't follow
Hi Timur,
On 08/28/2016 10:36 PM, Timur Tabi wrote:
> On Wed, Aug 24, 2016 at 9:29 AM, Sebastian Frias wrote:
>>
>> If this is really not possible, it forces the SoC manufacturer to expose
>> those properties in a different way, thus wasting a (seemingly) perfectly
>>
Commit-ID: f88eecfe2f22b2790e7527c0aaec14ea175919de
Gitweb: http://git.kernel.org/tip/f88eecfe2f22b2790e7527c0aaec14ea175919de
Author: Sebastian Frias
AuthorDate: Tue, 16 Aug 2016 16:05:08 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 2 Sep 2016 20:20:59 +0200
genirq/generic_chip
Commit-ID: 0c228919e04ddec195402296e7ebf2472ed6caef
Gitweb: http://git.kernel.org/tip/0c228919e04ddec195402296e7ebf2472ed6caef
Author: Sebastian Frias
AuthorDate: Tue, 2 Aug 2016 10:52:45 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 2 Sep 2016 18:06:50 +0200
irqdomain: Mask irq
Commit-ID: 895d3b95ed05f72a94f69ab52cb313915a6b889f
Gitweb: http://git.kernel.org/tip/895d3b95ed05f72a94f69ab52cb313915a6b889f
Author: Sebastian Frias
AuthorDate: Tue, 16 Aug 2016 16:05:08 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 2 Sep 2016 18:06:50 +0200
genirq/generic_chip
Commit-ID: ee26c013cdee0b947e29d6cadfb9ff3341c69ff9
Gitweb: http://git.kernel.org/tip/ee26c013cdee0b947e29d6cadfb9ff3341c69ff9
Author: Sebastian Frias
AuthorDate: Mon, 1 Aug 2016 16:27:38 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 2 Sep 2016 18:06:49 +0200
genirq/generic_chip
Commit-ID: f0c450eaa364cb77c778f2a46ee2aa3ff464b332
Gitweb: http://git.kernel.org/tip/f0c450eaa364cb77c778f2a46ee2aa3ff464b332
Author: Sebastian Frias
AuthorDate: Mon, 1 Aug 2016 16:27:53 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 2 Sep 2016 18:06:49 +0200
genirq/generic_chip
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
esolve the parameter to a constant
at compile time) or to warn during run-time, if the parameter given is
bigger than 32.
Signed-off-by: Sebastian Frias
---
include/linux/irq.h | 20 +++-
kernel/irq/generic-chip.c | 16
2 files changed, 23 insertions(+),
esolve the parameter to a constant
at compile time) or to warn during run-time, if the parameter given is
bigger than 32.
Signed-off-by: Sebastian Frias
---
include/linux/irq.h | 20 +++-
kernel/irq/generic-chip.c | 16
2 files changed, 23 insertions(+),
Hi,
I don't know if somebody has had the time to look at these patches, but if you
have comments (even if related to removing the "fixes" tag if you don't
consider this a fix) please let me know.
Best regards,
Sebastian
On 08/01/2016 04:27 PM, Sebastian Frias wrote:
Hi Thomas,
On 08/04/2016 12:05 PM, Thomas Gleixner wrote:
> On Tue, 2 Aug 2016, Sebastian Frias wrote:
>
>> Use IRQ_TYPE_SENSE_MASK on irq_domain_xlate_onetwocell()
>>
>> According to the xlate() callback definition, the 'out_type' parameter
>> needs to
Hi Thomas,
On 08/02/2016 10:31 AM, Sebastian Frias wrote:
>> So the proper way to do that is to split this into two patches:
>>
>> #1 Change the existing code to do the masking and explain why it is correct.
>>
>> #2 Refactor the code and get rid of the duplicated
wocell(), use it for irq_domain_xlate_onetwocell() as
well.
Fixes: 16b2e6e2f31d ("irq_domain: Create common xlate functions that device
drivers can use")
Signed-off-by: Sebastian Frias
---
kernel/irq/irqdomain.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kerne
se the
two previous ones to avoid code duplication.
Signed-off-by: Sebastian Frias
---
kernel/irq/irqdomain.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 1bdd3fe..28c09ab 100644
--- a/kernel/irq/irqdomain.c
++
wocell(), use it for irq_domain_xlate_onetwocell() as
well.
Fixes: 16b2e6e2f31d ("irq_domain: Create common xlate functions that device
drivers can use")
Signed-off-by: Sebastian Frias
---
kernel/irq/irqdomain.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kerne
Hi Thomas,
On 08/01/2016 07:07 PM, Thomas Gleixner wrote:
> On Mon, 1 Aug 2016, Sebastian Frias wrote:
>> Commit 16b2e6e2f31d ("irq_domain: Create common xlate functions that device
>> drivers can use") introduced three similar functions:
>&
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
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
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 ---
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 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
>
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]
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 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 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,
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 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 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
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 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
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.
>
This adds support for a second-gen irq router/controller present
on some Sigma Designs chips.
Signed-off-by: Sebastian Frias
---
This is a RFC because I have a few doubts:
1) I had to unroll irq_of_parse_and_map() in order to get the HW
IRQ declared in the device tree so that I can associate it
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
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/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
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
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
Hi Marc,
Thanks for your reply, please find my comments below.
On 06/10/2016 06:05 PM, Marc Zyngier wrote:
> On 10/06/16 16:37, Sebastian Frias wrote:
>> Hi,
>>
>> We are trying to write a driver for an interrupt controller (actually
>> more of a crossbar) for an ARM-b
Hi Marc,
Thanks for your input, please find my comments below.
On 06/11/2016 11:58 AM, Marc Zyngier wrote:
>> I think Sebastian is even more baffled by the DT mess
>> (sorry, intricacies) than I am.
>
> This mess is what has saved us from the apocalypse 5 years ago, and
> describing a complex sy
Hi Lennart,
Thanks for your input, please find my comments below.
On 06/13/2016 04:04 PM, Lennart Sorensen wrote:
> On Sat, Jun 11, 2016 at 05:37:51PM +0200, Mason wrote:
>> Only the name of the file was provided, not the path. I was not aware
>> that you already knew where to find it. I made no
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 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: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,
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 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
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: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 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
1 - 100 of 164 matches
Mail list logo
