On Tue, 25 Sep 2018 22:54:48 PDT (-0700), a...@brainfault.org wrote:
On Mon, Sep 17, 2018 at 7:58 PM Anup Patel wrote:
On Mon, Sep 17, 2018 at 7:44 PM Christoph Hellwig wrote:
>
> On Mon, Sep 10, 2018 at 10:08:58PM +0530, Anup Patel wrote:
> > > They could in theory IFF someone actually get t
On Mon, Sep 17, 2018 at 7:58 PM Anup Patel wrote:
>
> On Mon, Sep 17, 2018 at 7:44 PM Christoph Hellwig wrote:
> >
> > On Mon, Sep 10, 2018 at 10:08:58PM +0530, Anup Patel wrote:
> > > > They could in theory IFF someone actually get the use case through
> > > > the riscv privileged spec working g
On Mon, Sep 17, 2018 at 7:44 PM Christoph Hellwig wrote:
>
> On Mon, Sep 10, 2018 at 10:08:58PM +0530, Anup Patel wrote:
> > > They could in theory IFF someone actually get the use case through
> > > the riscv privileged spec working group.
> >
> > Their is no point in having each and every possib
On Mon, Sep 10, 2018 at 10:08:58PM +0530, Anup Patel wrote:
> > They could in theory IFF someone actually get the use case through
> > the riscv privileged spec working group.
>
> Their is no point in having each and every possible local interrupts
> defined by RISC-V spec because some of these wi
On Tue, Sep 11, 2018 at 09:27:45AM +0530, Anup Patel wrote:
> The list of currently defined RISC-V local interrupts will definitely grow
> based on my experience from ARM/ARM64 world.
>
> Like Thomas mentioned, we will definitely end-up having separate
> irqchip and irq_domain for RISC-V local int
On Tue, Sep 11, 2018 at 3:49 AM, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 09:37:59PM +0200, Thomas Gleixner wrote:
>> Processor local interrupts really should be architected and there are
>> really not that many of them.
>
> And that is what they are.
>
>> But well, RISC-V decided obvsio
On Mon, Sep 10, 2018 at 09:37:59PM +0200, Thomas Gleixner wrote:
> Processor local interrupts really should be architected and there are
> really not that many of them.
And that is what they are.
> But well, RISC-V decided obvsiouly not to learn from mistakes made by
> others.
I don't think that
On Mon, Sep 10, 2018 at 10:41:22PM +0530, Anup Patel wrote:
> RISC-V priv spec 1.10 defines the 9 bits in MIE and MIP registers and
> other bits are reserved.
>
> The unused bits in MIP are WIRI (reserved write ignored and read ignored)
> and unused bits in MIE are WPRI (reserved write preserve va
On Mon, 10 Sep 2018, Anup Patel wrote:
> On Mon, Sep 10, 2018 at 10:09 PM, Christoph Hellwig
> wrote:
> > On Mon, Sep 10, 2018 at 10:05:42PM +0530, Anup Patel wrote:
> >> I am quite sure RISC-V spec does not restrict the use of other
> >> local interrupts. Different CPU implementations can have t
On Mon, Sep 10, 2018 at 10:09 PM, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 10:05:42PM +0530, Anup Patel wrote:
>> I am quite sure RISC-V spec does not restrict the use of other
>> local interrupts. Different CPU implementations can have their
>> own local interrupts.
>
> Please take a lo
On Mon, Sep 10, 2018 at 10:05:42PM +0530, Anup Patel wrote:
> I am quite sure RISC-V spec does not restrict the use of other
> local interrupts. Different CPU implementations can have their
> own local interrupts.
Please take a look at sections 3.1.14 and 4.1.1 of the RISC-V privileged
spec 1.10.
On Mon, Sep 10, 2018 at 10:05 PM, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 10:02:09PM +0530, Anup Patel wrote:
>> You are thinking very much in-context of SiFive CPUs only.
>
> No. I think in terms of the RISC-V spec. I could care less about
> SiFive to be honest.
>
>> Lot of SOC vendo
On Mon, Sep 10, 2018 at 9:41 PM, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 06:07:12PM +0200, Thomas Gleixner wrote:
>> > Considering above, it is better to have a distinct irqchip and
>> > irq_domain for all local interrupts (just like this patch).
>>
>> If that's the future usage
>
> It'
On Mon, Sep 10, 2018 at 10:02:09PM +0530, Anup Patel wrote:
> You are thinking very much in-context of SiFive CPUs only.
No. I think in terms of the RISC-V spec. I could care less about
SiFive to be honest.
> Lot of SOC vendors are trying to come-up with their own CPUs
> and RISC-V spec does no
On Mon, Sep 10, 2018 at 9:43 PM, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 07:59:15PM +0530, Anup Patel wrote:
>> > Yes. external is chained and IPI is still handled explicitly.
>>
>> On riscv64, there are 64 local interrupts (i.e. per-CPU interrupts).
>
> There aren't. There are 9 righ
On Mon, Sep 10, 2018 at 07:59:15PM +0530, Anup Patel wrote:
> > Yes. external is chained and IPI is still handled explicitly.
>
> On riscv64, there are 64 local interrupts (i.e. per-CPU interrupts).
There aren't. There are 9 right now, which are your three below:
> Three of these local interru
On Mon, Sep 10, 2018 at 06:07:12PM +0200, Thomas Gleixner wrote:
> > Considering above, it is better to have a distinct irqchip and
> > irq_domain for all local interrupts (just like this patch).
>
> If that's the future usage
It's not, at least there has been no proposal for that so far, and I
d
On Mon, 10 Sep 2018, Anup Patel wrote:
> On Mon, Sep 10, 2018 at 7:19 PM, Christoph Hellwig wrote:
> > On Mon, Sep 10, 2018 at 03:45:42PM +0200, Thomas Gleixner wrote:
> >> > He has an irqchip that is called from the RISC-V exception handler
> >> > when the interrupt flag is set in scause and the
On Mon, Sep 10, 2018 at 7:19 PM, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 03:45:42PM +0200, Thomas Gleixner wrote:
>> > He has an irqchip that is called from the RISC-V exception handler
>> > when the interrupt flag is set in scause and then dispatches to one
>> > of: IPI, timer, actual
On Mon, Sep 10, 2018 at 03:45:42PM +0200, Thomas Gleixner wrote:
> > He has an irqchip that is called from the RISC-V exception handler
> > when the interrupt flag is set in scause and then dispatches to one
> > of: IPI, timer, actual irqchip.
>
> So the per cpu timer is the only per cpu interrup
On Mon, 10 Sep 2018, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 03:37:31PM +0200, Thomas Gleixner wrote:
> > > > Just a few weeks ago you said the contrary:
> > > >
> > > > http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html
> > >
> > > Sigh. Yes. Now that you remind
On Mon, Sep 10, 2018 at 03:37:31PM +0200, Thomas Gleixner wrote:
> > > Just a few weeks ago you said the contrary:
> > >
> > > http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html
> >
> > Sigh. Yes. Now that you remind me.
>
> Just for clarification. I had the impression tha
On Mon, 10 Sep 2018, Thomas Gleixner wrote:
> On Mon, 10 Sep 2018, Christoph Hellwig wrote:
> > On Sat, Sep 08, 2018 at 12:46:35PM +0200, Thomas Gleixner wrote:
> > > On Thu, 6 Sep 2018, Christoph Hellwig wrote:
> > >
> > > > Just as before: NAK to entirely pointless abstractions. Please stop
>
On Mon, 10 Sep 2018, Christoph Hellwig wrote:
> On Sat, Sep 08, 2018 at 12:46:35PM +0200, Thomas Gleixner wrote:
> > On Thu, 6 Sep 2018, Christoph Hellwig wrote:
> >
> > > Just as before: NAK to entirely pointless abstractions. Please stop
> > > beating the dead horse.
> >
> > I disagree. These
On Sat, Sep 08, 2018 at 12:46:35PM +0200, Thomas Gleixner wrote:
> On Thu, 6 Sep 2018, Christoph Hellwig wrote:
>
> > Just as before: NAK to entirely pointless abstractions. Please stop
> > beating the dead horse.
>
> I disagree. These interrupts very well fit into the percpu interupt
> mechani
On Thu, 6 Sep 2018, Christoph Hellwig wrote:
> Just as before: NAK to entirely pointless abstractions. Please stop
> beating the dead horse.
I disagree. These interrupts very well fit into the percpu interupt
mechanics and that allows them to be handled by all the generic mechanisms
as any othe
On Thu, Sep 6, 2018 at 7:36 PM, Christoph Hellwig wrote:
> Just as before: NAK to entirely pointless abstractions. Please stop
> beating the dead horse.
That's just your opinion without any concrete reasoning.
Even after explaining in various ways, you fail to understand the
flexibility brough
Just as before: NAK to entirely pointless abstractions. Please stop
beating the dead horse.
28 matches
Mail list logo
